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ABSTRACT 


This  research  evaluates  the  Automated  Non-Standard  Requisitioning  System 
(ANSRS)  to  determine  the  feasibility  of  implementing  this  technology  as  a 
replacement  to  the  manual  nonstandard  procurement  processes  currently  employed 
within  Submarine  Forces,  Pacific  (SUBPAC).  Manual  nonstandard  procurement 
processes  for  both  surface  ships  and  submarines,  as  well  as  the  prototype  ANSRS 
process  implemented  on  several  surface  ships  and  shore  commands,  are  discussed, 
diagrammed,  and  quantified.  These  processes  are  then  compared  and  contrasted,  and 
appropriate  conclusions  are  derived. 

The  primary  conclusion  is  that  ANSRS  should  be  implemented  within  SUBPAC, 
contingent  upon  the  resolution  of  several  significant  problems. 


v 


vi 


TABLE  OF  CONTENTS 


I.  INTRODUCTION . 1 

A.  BACKGROUND . 1 

B.  OBJECTIVE . 3 

C.  SCOPE  . 3 

D.  METHODOLOGY . 4 

E.  ORGANIZATION  OF  STUDY . 5 

II.  LITERATURE  REVIEW  AND  THEORETICAL  FRAMEWORK . 7 

A.  NONSTANDARD  MATERIAL . 7 

1 .  Definitions . 7 

a.  “ Traditional  ”  Nonstandard  Material . 8 

b.  Commercial  Off  The  Shelf  (COTS)/Non-Developmental  . 8 

Item  (NDI)  and  CANDI 

2.  Nonstandard  Material  Requirement  Determination . 9 

3.  Nonstandard  Material  Procurement  Methods . 9 

a.  Large  Purchases . 10 

b.  Small  Purchases  Without  a  Credit  Card . 10 

c.  Small  Purchase  With  a  Credit  Card . 10 

B.  CYCLE  TIME . 11 

1 .  Requisition  Preparation  Time  (RPT) . 11 

2.  Requisition  Submission  Time  (RST) . 1 1 

3 .  Procurement  Administrative  Lead  Time  (PALT) . 12 

C.  EC/EDI  . 12 

1.  Definitions . 12 

a.  Electronic  Commerce  (EC) . 12 

b.  Electronic  Data  Interchange  (EDI) . 12 

2.  Origins  of  EDI . 13 

3 .  Benefits  of  EDI . 13 

4.  Federal  Acquisition  Streamlining  Act  (FAS A)  of  1994 . 13 

5.  Commercial  Software  Packages . 14 

D.  ANSRS  . 14 

1.  Introduction . 14 

2.  Precursors  to  ANSRS . 15 

a.  Technical  Screening  Expert  System  (TSES) . 15 

b.  Standard  Processing  Environment  for  Electronic . 16 

Documents  (SPEED) 

c.  APADE  Off  Line  (AOL) . 16 

3 .  Program  Description . 16 

4.  Program  Objectives  and  Benefits . 18 

a.  Integrated  System . 18 

b.  Non-Standard  Database  (NSDB) . 19 

c.  Reduced  Workload . 19 

d.  Enhanced  LRT . 19 


vii 


E.  MANUAL  PROCUREMENT  PROCESS  FLOW . 20 

1.  Surface  Ship . 20 

a.  Process  Without  a  Credit  Card . 20 

b.  Process  With  a  Credit  Card . . 21 

2.  Submarine . 25 

F.  CHAPTER  SUMMARY . . . 26 

m.  PROCUREMENT  AND  ANSRS . 29 

A.  ANSRS  IMPLEMENTATION . 29 

1 .  Background . 29 

a.  Strategy . 29 

b.  Schedule . 30 

2.  Responsibilities . 30 

a.  Prototype  Version . 30 

b.  Windows  NT  Version . 30 

c.  “ANSRS-Air” . 30 

d.  Deep  Technical  Screening . 31 

B.  PROTOTYPE  AFLOAT  CUSTOMER  MODULE . 31 

1 .  Installation  and  Setup . 31 

2.  Operation . 32 

C.  MANUAL  AND  ANSRS  PROCUREMENT  PROCESS  FLOWS . 32 

1 .  Manual  Process  Flow  Through  Surface  Ship  to  FISC  and  Buyer . 33 

a.  Manual  Requisition  Preparation  Time  (RPT) . 34 

b.  Manual  Requisition  Submission  Time  (RST)  and  Manual . 36 

Procurement  Administrative  Lead  Time  (PALT) 

2.  Manual  Process  Flow  Through  Submarine  to  SLSC  to  FISC  and  Buyer ....  3 8 

a.  Manual  Requisition  Preparation  Time  (RPT) . 39 

b.  Manual  Requisition  Submission  Time  (RST)  and  Manual . 39 

Procurement  Administrative  Lead  Time  (PALT) 

3.  ANSRS  Process  Flow  Through  Surface  Ship  to  FISC  and  Buyer . 41 

a.  ANSRS  Requisition  Preparation  Time  (RPT) . 42 

b.  ANSRS  Requisition  Submission  Time  (RST)  and  ANSRS . 44 

Procurement  Administrative  Lead  Time  (PALT) 

D.  CHAPTER  SUMMARY . 46 

IV.  DATA  COLLECTION  AND  ANALYSIS . 53 

A.  QUESTIONNAIRE  BACKGROUND . 53 

B.  QUESTIONNAIRE  RESPONSES  AND  ANALYSES . 54 

1.  Manual  Open  Purchase  Process  (Pre- ANSRS,  Pre-Credit  Card) . 54 

2.  IMP  AC  Credit  Card . 56 

3.  ANSRS  Training . 57 

4.  ANSRS  Usage . 60 

5.  Miscellaneous . 64 

6.  Additional  Comments . 65 

C.  ANSRS  IMPLEMENTATION  AT  FISC  PEARL  HARBOR . 66 

D.  MEASURES  OF  EFFECTIVENESS  AND  COST . 66 


viii 


E.  CHAPTER  SUMMARY . 68 

V.  CONCLUSIONS  AND  RECOMMENDATIONS . 71 

A.  CONCLUSIONS  AND  RECOMMENDATIONS . 71 

B.  PERIPHERAL  ISSUES . 75 

1 .  Credit  Card  Usage . 75 

2.  Technical  Libraries . 75 

APPENDIX  A:  TECHNICAL  SCREENING  EXPERT  SYSTEM  (TSES) . 77 

CAPABILITIES 

APPENDIX  B:  STANDARD  PROCESSING  ENVIRONMENT  FOR  . 79 

ELECTRONIC  DOCUMENTS  (SPEED)  CAPABILITIES 

APPENDIX  C:  ANSRS  OBJECTIVES . 80 

APPENDIX  D:  LIST  OF  SITES  IMPLEMENTED . 85 

APPENDIX  E:  QUESTIONNAIRE . 86 

APPENDIX  F:  TOP  REASONS  WHY  PROCUREMENT  DOCUMENTS  GET  . 90 

SENT  BACK  TO  SHIP  FROM  FISC 

LIST  OF  REFERENCES . 91 

INITIAL  DISRIBUTION  LIST . 93 


IX 


L  INTRODUCTION 


The  purpose  of  this  thesis  is  to  evaluate  the  functionality  and  cost  of  the 
Automated  Non-Standard  Requisitioning  System  (ANSRS)  program.  It  will  be  evaluated 
in  the  context  of  fleet  usage  and  its  application  in  the  submarine  community.  The  dual 
goals  of  shifting  to  a  paperless  environment  and  reducing  costs  have  led  to  the 
development  of  automated  processing  procurement  technology  such  as  ANSRS; 
improvements  in  readiness  are  meant  to  be  a  byproduct  of  implementation.  This  chapter 
provides  background  information  on  the  driving  forces  behind  the  ANSRS  program. 
Additionally,  the  objective,  scope,  methodology,  and  organization  of  this  study  are 
described. 

A.  BACKGROUND 

In  response  to  the  Government  Performance  and  Results  Act  (GPRA)1  and  the 
most  recent  Quadrennial  Defense  Review  (QDR),  the  Secretary  of  Defense  directed  a  new 
strategic  approach  to  the  management  and  operation  of  national  defense  efforts  [Refs.  1 
and  2],  The  Department  of  Defense  (DoD)  Logistics  Strategic  Plans  (LSP)  for  fiscal  years 
1995  and  1998  delineate  the  framework  for  implementing  the  new  strategic  approach 
[Refs.  3  and  4],  The  evolution  of  the  ANSRS  program  can  be  directly  matched  to  several 
of  the  1998  LSP’s  Fundamental  Principles  and  Logistics  Management  Imperatives. 

These  include: 

Fundamental  Principles 

1 .  Logistics  organizations  should  be  streamlined  and  consolidated 

whenever  possible,  and  unneeded,  uneconomical  or  redundant  logistics 
process  segments,  cycles,  nodes  and  layers  should  be  reduced  or 
eliminated; 

1  P.L.  103-62 
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2.  Access  to  accurate  and  timely  logistics  information  should  be  provided 
to  all  customers;  and 

3.  Performance  should  be  measured  based  on  improvement  of  customer 
support  and  reducing  total  logistics  costs. 

Logistics  Management  Imperatives 

1 .  Reengineer  business  practices  to  increase  efficiency  and  reduce  logistics 
resource  requirements; 

2.  Reduce  logistics  cycle  and  response  times; 

3 .  Effectively  employ  new  technologies  to  improve  performance  and 
reduce  costs;  and 

4.  Improve  the  effectiveness  of  the  logistics  workforce. 

Although  many  of  the  Navy’s  supply  processes  have  been  automated  over  the 

years,  the  purchase  of  nonstandard  inventory  and  the  nonstandard  procurement  process 
remains  bound  in  a  manual,  paper  environment.  During  visits  to  ashore  and  afloat 
activities  to  ascertain  their  need  for  more  expedient  technical  screening  and  requisition 
submission  methods,  file  drawers  full  of  old  paperwork  were  discovered.  Cumbersome 
technical  manuals,  drawings,  and  microfiche  libraries  were  still  being  used  to  screen 
requirements.  Afloat,  technical  screeners  were  not  able  to  share  data,  creating 
redundancies  and  resulting  in  excessive  requisition  processing  time  (RPT)  and  requisition 
submission  time  (RST).  Ashore,  Fleet  and  Industrial  Supply  Centers  (FISCs)  acted  as 
independent,  stand-alone  regional  providers  of  next-level  procurement  services  [Ref.  5]. 
Frequently,  information  provided  from  the  end-user  activity  to  the  FISC  was  incomplete 
or  required  further  clarification;  the  inability  of  the  FISCs  and  end-users  to  easily 
communicate  and  correct  paperwork  deficiencies  often  resulted  in  substantial  delays  in 
contracting  for  the  needed  material  and  excessive  logistics  response  time  (LRT). 

The  Naval  Supply  Systems  Command  (NAVSUP),  in  its  continuing  efforts  to 
reduce  costs  of  operations  through  standardization,  centralization,  and  downsizing,  and  to 
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consolidate  the  entire  nonstandard  procurement  process  at  the  Navy  Inventory  Control 
Point  Mechanicsburg  (NAVICP-M),  developed  a  PC-based  software  package,  ANSRS. 
Customer  Support  Modules  at  each  end-user  activity.  Procurement  Activity  Modules  at 
each  FISC  procurement  site,  and  the  Central  Database  Module  (CDB),  or  Host  Module  at 
the  Central  Technical  Activity  (CTA),2  are  linked  via  electronic  data  interchange  (EDI) 
methods  designed  to  provide  a  paperless,  streamlined  communication  network  . 

B.  OBJECTIVE 

The  objective  of  this  study  is  to  determine  the  feasibility  of  implementing  ANSRS 
technology  as  a  replacement  to  manual  nonstandard  procurement  processes  currently  used 
within  Submarine  Forces,  Pacific  (SUBPAC). 

C.  SCOPE 

In  this  study,  five  areas  are  examined:  1)  current  technologies  and  processes 
relevant  to  ANSRS  development  and  ANSRS  efficacy;  2)  ANSRS  technology  and 
program  objectives;  3)  manual  nonstandard  procurement  processes,  both  afloat  and 
ashore;  4)  measures  of  effectiveness;  and  5)  performance  of  the  ANSRS  prototype 
onboard  surface  ships  and  at  shore  procurement  activities.  The  first  and  second  areas 
focus  on  the  past  and  provide  the  reader  relevant  background  information.  The  final  three 
areas  present  the  data  supporting  the  conclusions  and  recommendations  pertinent  to  the 
objective  of  this  study. 

The  ANSRS  program  is  still  in  the  introduction  and  testing  phase  of  its  life  cycle. 
This  circumstance  has  limited  the  research  of  this  study;  how  well  the  ANSRS  program 
integrates  and  will  integrate  with  other  DoD  and  Navy  logistics  improvement  initiatives  is, 

2  NAVICP-M  (Code  054),  Data  Integrity  Division 
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at  this  point,  in  the  realm  of  educated  speculation.  This  research,  unless  otherwise  noted, 
assumes  that  the  ANSRS  program  will  not  adversely  affect  other  logistics  improvement 
initiatives  currently  underway. 

D.  METHODOLOGY 

This  study  began  with  research  into  the  literature  associated  with  the  ANSRS 
program  and  its  claim  to  improve  the  manual  nonstandard  procurement  process. 
NAVSUP  and  NAVICP-M  personnel  were  interviewed  to  appraise  and  report  ANSRS 
program  objectives  and  expected  benefits.  The  prototype  Afloat  Customer  [Support] 
Module  was  used  to  research  and  simulate  the  end-user’s  experience  with  ANSRS.  The 
manual  nonstandard  requisitioning  process,  from  the  perspective  of  the  submarine  end- 
user,  was  ascertained  through  interviews  with  supply  personnel  from  USS  KEY  WEST 
(SSN  722),  homeported  in  Pearl  Harbor,  Hawaii  and  by  “walking  through”  requirements 
from  the  end-user  to  the  Submarine  Logistics  Support  Center,  Pearl  Harbor  Detachment 
(SLSC-PH)  to  FISC  Pearl  Harbor  (FISC-PH).  Interviews  were  conducted  with  FISC 
personnel  to  identify  the  problems  and  choke  points  currently  experienced  with  the 
ANSRS  process,  and  to  document  the  perceived  benefits  and/or  deficiencies  associated 
with  ANSRS  implementation.  SUBPAC  personnel,  including  the  Force  Supply  Officer 
and  Force  Storekeeper,  were  interviewed  to  ascertain  perspectives  and  identify  concerns 
with  the  ANSRS  program  and  its  future  usefulness  to  readiness  improvement.  The 
perspectives  of  non-SUBPAC,  ANSRS-capable  activities  were  ascertained  through 
interviews  and  questionnaires.  Alternative  or  hybrid  nonstandard  procurement  method 
studies  were  reviewed.  A  literature  search  of  internet  resources  was  also  conducted. 
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E.  ORGANIZATION  OF  STUDY 


The  remaining  chapters  in  this  thesis  are  organized  as  follows.  Chapter  II  provides 
a  literature  review  and  theoretical  framework  for  this  study.  Chapter  III  orients  the  reader 
to  ANSRS  implementation  background  issues  and  a  comparison  of  the  manual  and 
ANSRS  procurement  process  flows.  Chapter  IV  presents,  analyzes,  and  provides 
interpretations  of  the  data.  Chapter  V  presents  conclusions  and  recommendations  relevant 
to  the  objective  of  this  study. 
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H.  LITERATURE  REVIEW  AND  THEORETICAL  FRAMEWORK 


This  chapter  introduces  the  reader  to  the  literature  requisite  to  understand  both  the 
theoretical  framework  and  the  remaining  discourse  of  this  study.  The  theoretical 
framework  of  this  study  is  centered  around  two  elements  of  the  manual  nonstandard 
procurement  process:  Procurement  Cycle  Time — defined  as  the  interval  between  the 
moment  the  end-user  identifies  a  material  or  service  need  to  the  moment  the  contract  for 
that  need  is  awarded — and  related  costs.  The  two  are  not  unrelated;  even  in  the  Navy, 
time  is  money.  The  Navy’s  modus  operandi  for  reducing  Cycle  Time  and  costs  associated 
with  the  nonstandard  procurement  process,  via  the  ANSRS  program,  is  also  an  important 
theoretical  issue.  The  flow  of  the  current  manual  procurement  process  is  briefly 
presented.  A  more  detailed  presentation  of  the  manual  procurement  process  will  be 
discussed,  diagrammed,  and  quantified  in  Chapter  III,  as  will  the  ANSRS  flow  for  surface 
ships  and  FISCs. 

A.  NONSTANDARD  MATERIAL 

1.  Definitions 

Nonstandard  materials  are  simply  those  items  of  supply  that  are  not  centrally 
managed  or  procured  for  supply  system  stock.  Conversely,  items  that  are  centrally 
managed  or  procured  for  supply  system  stock  are  known  as  “standard”  material,  assigned 
a  National  Stock  Number  (NSN),  and  managed  in  accordance  with  federal  law  and  the 
precepts  of  the  Federal  Catalog  System.  ANSRS  deals  solely  with  nonstandard  items  but 
can  also  be  used  for  technical  screening  of  standard  items. 


7 


a.  “ Traditional ”  Nonstandard  Material 

The  NAVSUP  P-485  lists  categories  of  items  exempt  from  the  Federal 
Catalog  System,  such  as  items  procured  on  a  one-time  basis  and  items  intended  solely  for 
local  use  or  consumption  [Ref.  6],  Examples  include  equipage,  such  as  facsimile 
machines,  and  some  habitability  improvement  material,  such  as  certain  types  of  floor  tile 
and  paint.  Major  equipment,  repairable  components,  and  “throw  away”  repair  parts  are 
generally  assigned  an  NSN.  However,  it  is  not  always  readily  apparent  whether  a 
particular  item  is,  or  has,  an  acceptable  substitute  assigned  an  NSN.  Since  the  current 
hierarchy  of  mandatory  sources  of  supply  generally  dictates  ordering  standard  material 
before  resorting  to  open  procurement,  it  is  imperative  to  screen  one’s  requirements  against 
available  Federal  Catalog  System  databases  such  as  FEDLOG,  HAYSTACK,  or 
PARTSMASTER.3 

b.  Commercial  Off  The  Shelf  (COTS)/Non-Developmental  Item 
(NDI)  and  CANDI 

As  a  result  of  the  Federal  Acquisition  Reform  Act  of  19964,  and  in  an  effort 
to  substantially  reduce  equipment  developmental  and  life  cycle  support  costs.  Hardware 
Systems  Commands  (HSC)  are  increasingly  seeking  ways  to  exploit  COTS  and  NDI 
technologies  [Ref.  7],  COTS  and  NDI  both  refer  to  previously  developed  items;  the  main 
difference  is  that  COTS  technologies  are  developed  in  the  private  sector  and  usually  have 
commercial  applications  whereas  NDI  technologies  are  developed  within  the  government 
and  usually  have  no  commercial  applications.  However,  there  are  examples  of  COTS 

3  FEDLOG  is  commonly  used  throughout  the  fleet,  including  submarines  and  ships.  HAYSTACK  and 
PARTSMASTER  are  typically  available  only  at  larger  technical  screening  activities. 

4  P.L.  104-106 
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technologies  developed  solely  for  government  use  and  NDI  technologies  having 
commercial  applications.  Therefore,  the  encompassing  term  “CANDI,”  which  stands  for 
COTS  and  Non-Developmental  Item,  is  often  instead  used,  and  will  be  used  in  this  study. 
There  are  two  “types”  of  CANDI:  HSC  directed  and  Fleet  directed. 

2.  Nonstandard  Material  Requirement  Determination 

A  requirement  that  is  identified  as  nonstandard  (i.e.,  without  an  assigned  NSN)  can 
normally  be  procured  through  one  of  three  types  of  open  purchase  methods.  Various 
regulations,  particularly  NAVSUP  Instruction  4200. 85C,  which  incorporates  pertinent 
aspects  of  the  Federal  Acquisition  Regulation  (FAR)  and  the  DoD  Federal  Acquisition 
Regulation  Supplement  (DFARS)  for  simplified  acquisition  procedures  and  credit  card 
purchases  (see  paragraph  A3b  and  c  below),  allow  open  procurement  of  standard  material 
or  waiver  of  mandatory  sources  of  supply  in  some  cases  [Ref.  8],  Here,  too,  it  is 
imperative  that  one  be  able  to  screen  one’s  requirements  accurately.  ANSRS  provides  the 
end-user  the  capability  to  access  various  types  of  reference  material  online,  including 
acquisition  regulations. 

3.  Nonstandard  Material  Procurement  Methods 

It  is  important  to  note  that  all  of  the  end-users  of  this  study,  both  those  that 
currently  have  ANSRS  implemented  within  their  command  and  those  in  the  submarine 
community,  use  funds  derived  from  a  congressional  appropriation  entitled  Operations  and 
Maintenance,  Navy  (O&MN)  to  procure  supplies  and  services.  End-user  commands  may 
use  other  appropriated  (and  non-appropriated)  funds  for  such  things  as  subsistence  and 
expensive  computer  systems.  Although  ANSRS  deals  with  all  monetary  amounts  and 
other  appropriation  types  used  to  procure  material  and  services,  the  discussion  in  the 
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remainder  of  this  chapter  applies  exclusively  to  procurements  using  O&MN  funds. 

«.  Large  Purchases 

Large  purchases  are  procurements  that  exceed  the  simplified  acquisition 
threshold  of  $100,000,  or  $200,000  for  contingency  requirements  outside  of  the  United 
Stated  [Ref.  8],  Additionally,  O&MN  funds  cannot  be  used  for  minor  construction 
projects  in  excess  of  $500,000. 

b.  Small  Purchases  Without  a  Credit  Card 

Procurements  that  do  not  exceed  the  simplified  acquisition  procedures 
thresholds  above  are  commonly  called  “small  purchases”  or  “simplified  purchases”  and,  as 
implied,  are  governed  by  less  stringent  acquisition  regulations  than  are  large  purchases. 
However,  unless  the  contracting  office  making  the  purchase  has  been  FACNET  certified, 
small  purchases  cannot  exceed  $50,000  [Ref.  8], 5 

c.  Small  Purchases  With  a  Credit  Card 

A  procurement  of  authorized  supplies  and  services,  the  aggregate  amount 
of  which  does  not  exceed  $2,500,  is  known  as  a  “micro-purchase.”  In  accordance  with 
the  National  Performance  Review  of  1993,  credit  cards  are  to  be  used  for  micro-purchases 
[Ref.  9],  There  are,  however,  certain  restrictions  to  using  credit  cards;  for  example,  credit 
cards  cannot  be  used  to  procure  hazardous  materials,  or  services  of  any  type  [Ref.  8],  The 
main  advantage  of  a  micro-purchase  is  that  a  contract  can  be  awarded  without  soliciting 


5  The  Federal  Acquisition  Computer  Network  (FACNET)  is  the  government-wide  systems  architecture  for 
the  acquisition  of  supplies  and  services.  It  provides  for  electronic  data  interchange  (EDI)  of  acquisition 
information  between  the  government  and  the  private  sector,  employs  nationally  and  internationally 
recognized  data  formats,  and  provides  universal  user  access.  FACNET  certification  requires  that  more 
than  75  percent  of  an  agency’s  small  purchases  exceeding  $2,500  be  made  via  FACNET.  See  FAR  4.504 
and  Ref.  8  for  complete  certification  requirements. 
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competitive  quotations,  as  long  as  the  contracting  officer  determines  that  the  price  is 
reasonable.  The  advantages  of  using  the  credit  card  are  a  streamlined  (and,  currently,  a 
less  expensive)  payment  procedure  and  a  reduction  in  paperwork  requirements.  These 
advantages  save  time.  NAVICP-M  data  indicates  that  approximately  80  percent  of  all 
purchases  are  micro-purchases  and,  unless  restricted,  are  eligible  for  procurement  with  a 
credit  card. 

B.  CYCLE  TIME 

The  term  “Cycle  Time”  will  be  used  in  this  study  and,  as  such,  is  defined  as  the 
interval  between  the  moment  the  end-user  identifies  a  material  or  service  need  to  the 
moment  the  contract  for  that  need  is  awarded.  In  this  study.  Cycle  Time  does  not  include 
manufacturing  lead  times  and  shipment/transportation  times  because  ANSRS  is  not 
designed  to  automate  those  actions.  Cycle  Time  is  broken  down  into  the  following  three 
segments: 

1 .  Requisition  Preparation  Time  (RPT) 

RPT  is  the  interval  between  the  moment  the  end-user  identifies  a  need  to  the 
moment  when  the  procurement  document  is  completed  onboard  the  ship  or  submarine. 
RPT  activities  include  conducting  initial  research,  ordering,  preparing  the  procurement 
document,  conducting  technical  screening,  obtaining  requisite  approvals,  and  assigning  a 
requisition  number. 

2.  Requisition  Submission  Time  (RST) 

RST  is  the  interval  between  the  moment  when  the  procurement  documented  is 
completed  onboard  the  ship  or  submarine  to  the  moment  the  document  is  accepted  by  the 
procurement  activity.  “Acceptance”  does  not  occur  until  the  procurement  activity  is 
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satisfied  with  the  accuracy  of  the  procurement  document.  Therefore,  if  the  procurement 
activity  returns  a  previously  delivered  procurement  document  to  the  ship  or  submarine 
because  of  inaccurate  or  missing  information,  the  resultant  delay  is  part  ofRST. 

3.  Procurement  Administrative  Lead  Time  (PALT) 

PALT  is  the  interval  between  the  moment  the  procurement  document  is  accepted 
at  the  procurement  activity  to  the  moment  the  contract  is  awarded  (i.e.,  the  amount  of 
time  it  takes  a  buyer  to  make  a  buy).  PALT  standards  vary  among  different  procurement 
activities,  even  those  at  the  same  level  such  as  FISCs. 

C.  EC/EDI 

1.  Definitions 

a.  Electronic  Commerce  (EC) 

EC  is  the  paperless  exchange  of  business  information  using  Electronic  Data 
Interchange  (EDI),  electronic  mail  (e-mail),  computer  bulletin  boards,  FAX,  electronic 
funds  transfer  (EFT),  and  other  similar  technologies  [Ref.  10], 

b.  Electronic  Data  Interchange  (EDI) 

EDI  is  the  computer-to-computer  exchange  of  business  information  using  a 
public  standard  such  as  ANSI-X12  or  EDIFACT.6  EDI  is  a  central  part  of  EC,  because  it 
enables  businesses  to  electronically  exchange  business  information  faster,  cheaper,  and 
more  accurately  than  is  possible  using  paper-based  systems  [Ref.  10],  ANSRS 
incorporates  EDI  in  its  program  capabilities. 


6  See  Ref.  9,  Chapter  7  for  American  National  Standards  Institute  (ANSI)  standards,  conventions,  and 
formats.  U.S.  Government  agencies  use  the  ANSI  X12  format.  EDIFACT  is  used  internationally  and  is 
the  United  Nations  standard. 
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2. 


Origins  of  EDI 


EDI  was  first  used  in  the  transportation  industry  more  than  20  years  ago  by 
ocean,  motor,  air,  and  rail  carriers  and  associated  shippers,  brokers,  customs,  freight 
forwarders,  and  bankers.  The  first  set  of  industry  EDI  standards  were  developed  by  the 
Transportation  Data  Coordinating  Committee  (TDCC)  and  consisted  of  45  transaction 
sets  for  the  transportation  industry.  ANSI  X12  standards  were  developed  later  and  are 
based  upon  the  TDCC  syntax  and  format.  More  than  50,000  private-sector  companies  in 
the  United  States  currently  use  EDI.  Many  more  use  it  internationally  [Ref.  10], 

3.  Benefits  of  EDI 

As  discussed  in  the  first  paragraph  of  this  study,  shifting  to  a  paperless 
environment  and  reducing  costs  are  the  dual  goals  of  automating  the  nonstandard  material 
procurement  process.  The  stated  benefits  of  EDI  dovetail  with  these  goals.  Those 
benefits  are  [Ref.  10]: 

1 .  Improvements  in  overall  quality  through  better  record-keeping,  fewer 
data  errors,  reduced  processing  time,  and  less  reliance  on  human 
interpretation  of  data; 

2.  Lower  mailing  costs  will  be  realized  through  reduced  postage  and  other 
mailing  costs  and  elimination  of  lost  documents; 

3 .  Reduced  order  time  and  less  paperwork; 

4.  Faster  billing.  Since  orders  are  processed  sooner,  billing  and  closeout 
can  occur  sooner;  and 

5.  Better  information  for  management  decision  making,  including  more 
accurate  audit  trails. 

4.  Federal  Acquisition  Streamlining  Act  (FASA)  of  19947 

FASA  was  enacted  to  simplify  and  streamline  the  federal  procurement  process. 
Intended  to  significantly  change  how  the  Government  does  business,  FASA  repealed  or 


7  P.L.  103-355 
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substantially  modified  more  than  225  provisions  of  the  law  to  reduce  paperwork  burdens, 
facilitate  the  procurement  of  commercial  products,  enhance  the  use  of 
simplified  procedures  for  small  purchases,  transform  the  procurement  process  to 
Electronic  Commerce,  and  improve  the  efficiency  of  the  laws  governing  the  procurement 
of  goods  and  services.  The  most  significant  provisions  of  FASA  include  [Ref.  10]: 

1 .  Emphasizing  the  procurement  of  commercial  products; 

2.  Streamlining  procurement  procedures  under  an  elevated  small  purchase 
threshold  (see  paragraph  A3«  above  for  current  thresholds); 

3 .  Implementing  FACNET ; 

4.  Establishing  uniformity  in  the  procurement  system;  and 

5.  Improving  protest  and  oversight  processes  and  authorizing  specific 
pilot  programs 

5.  Commercial  Software  Packages 

There  are  a  number  of  commercially  available  software  procurement  packages  that 
profess  a  high  degree  of  adaptability  and  flexibility.8  All  of  those  reviewed  by  the  author 
are  Windows-based  and  appear  to  be  modifiable  to  conform  with  Navy-specific  automated 
nonstandard  material  purchasing  requirements.  However,  commercial  software  packages 
were  not  considered  by  NAVSUP  because  the  complexities  of  the  tasking,  file  interface 
requirements,  and  the  operating  environment  were  judged  to  be  too  unique  for  any 
CANDI  program  to  fully  adapt/accommodate  [Ref.  11]. 

D.  ANSRS 

1.  Introduction 

Informal  research  conducted  by  NAVSUP  41  and  the  NAVSUP  ANSRS  Program 
Manager  for  FY94-96  estimated  that  5-6%  (~  440,000)  of  all  requisitions  submitted  by  all 
Navy  activities  were  for  nonstandard  material  [Ref.  1 1].  It  was  intended  to  determine,  in  a 

8  The  author  reviewed  six  commercial  software  brochures. 
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general  sense,  whether  automating  nonstandard  material  procurement  processes  was  a 
worthwhile  objective  to  pursue.  Standard  material  counts  were  derived  from  both 
NAVICPs  whereas  nonstandard  counts  were  derived  from  FISCs.  Manually  processing 
such  a  large  number  of  requisitions  requires  a  great  deal  of  resources,  in  terms  of  labor, 
paper,  time,  and  money,  and  presented  an  ideal  opportunity  to  effect  cost  savings  and 
eliminate  inefficiencies  through  automation.  Therefore,  in  late  May  1995,  NAVSUP  04 
directed  the  development  of  a  system  to  automate  the  processing  of  nonstandard 
procurements  and  record  results  of  technical  screening  actions,  to  be  delivered  by  April 
01,  1996.  Along  with  the  functional  and  operational  complexities  discussed  in  paragraph 
C5,  and  the  desire  to  combine  and  standardize  similar  but  separate  efforts  then  underway 
to  automate  nonstandard  procurement  and  modernize  technical  screening  research  tools, 
this  time  frame  constraint  precluded  any  serious  consideration  of  commercially  available 
software  packages  [Ref.  1 1],  Instead,  under  NAVSUP  guidance  and  CTA  control, 
programmers  from  the  Fleet  Material  Support  Office  (FMSO)  merged  the  full 
functionalities  of  two  ANSRS  precursors,  TSES  and  SPEED. 

2.  Precursors  to  ANSRS 

a.  Technical  Screening  Expert  System  (TSES) 

TSES  incorporated  most  functionalities  of  the  envisioned  automated 
nonstandard  procurement  system  and  was  therefore  designated  to  form  the  core  program, 
to  which  other  required  functions  would  be  added.  Developed  at  NAVICP-M,  TSES 
provided  a  technical  screening  function  which  focused  on  the  identification  of  hazardous 
material  (HAZMAT)  substitutes  and  compliance  with  U.S.  laws  and  international  treaties 
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concerning  HAZMAT,  ozone-depleting  substances,  and  plastics  disposal.  Appendix  A 
lists  TSES  capabilities  [Ref.  13]. 

b.  Standard  Processing  Environment  for  Electronic  Documents 

(SPEED) 

Developed  at  FISC  Oakland,  SPEED  is  mainly  a  vehicle  for  nonstandard 
requisition  transmission  and  status  update  reception.  SPEED  is  capable  of  transmitting 
completed  work  to  the  Automated  Procurement  and  Accounting  Data  Entry  (APADE) 
system,  the  FISCs’  system  for  contracting.  Appendix  B  lists  SPEED  capabilities  [Ref. 
13]. 

c  APADE  Off  Line  (AOL) 

As  noted  earlier,  the  full  functionalities  of  TSES  and  SPEED  were 
retained.  The  functionalities  of  AOL,  however,  were  not  considered  because  AOL 
requires  the  afloat  end-user  to  learn  the  file  structure  and  submission  procedures  for 
APADE.  This  requirement  is  counter  to  NAVSUP’s  strategic  goal  of  reducing  workload 
afloat  [Ref.  11]. 

3.  Program  Description 

NAVSUP’s  ANSRS  Information  Pamphlet  describes  the  ANSRS  program  as 
follows  [Ref.  5]: 


ANSRS  is  an  automated  (paperless  environment)  program  which 
performs  a  basic-level  technical  review  (customer  level)  of  each 
requirement,  generates  an  electronic  requisition,  downloads  [the] 
requisition  via  the  Streamlined  Alternative  Logistics  Transmission  System 
(SALTS)  and  forwards  it  to  the  CTA/FISC.  ANSRS  automatically  screens 
incoming  electronic  requisitions.  Validations  and  edits  are  built  into  the 
system  and  communication  between  all  participants  occurs  via 
SALTS/EDI,  and  Military  Standard  Transaction  Requisitioning  and  Issue 
Procedures  (MELSTRIP)  via  Uniform  Inventory  Control  Program 
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(UlCPyUniform  Automated  Data  Processing  System  (UADPS)/Shipboard 
Uniform  Automated  Data  Processing  System  (SUADPS)  transmissions,  so 
as  to  maintain  status  and  demand  criteria.  The  system  screens  out 
exceptions  and  queues  those  items  with  inadequate  data  for  manual  review. 
As  part  of  this  process,  ANSRS  produces  a  database  of  all  nonstandard 
requisitions,  resident,  maintained  and  updated  at  the  CTA.  A  tailored 
version  will  be  distributed  via  CD-ROM  as  part  of  the  Customer  and 
FISC/Procurement  modules.  As  records  of  new  items  are  added  to  the 
CTA  nonstandard  database,  providing  historical  data  and  past  procurement 
history,  the  program  will  become  more  proficient  at  screening  requisitions, 
expediting  technical  screening  of  subsequent  requisitions  for  same  or 
similar  items.  Savings  with  respect  to  purchase  of  hazardous  materials  and 
storage  of  these  materials  will  be  realized  since  each  technical  screener  at 
the  customer,  FISC  and  CTA  level  will  have  access  to  technical 
information  identifying  these  items  and  the  methodology  necessary  to 
process  them  correctly. 

The  centralization  of  the  nonstandard  requisitioning  process  at  the  CTA 
will  create  a  central  repository  for  data  to  allow  collection  or  part- 
numbered  information,  visibility  of  all  part-numbered  buys  and  will 
facilitate  faster  and  more  efficient  service  to  the  customer.  In  the  long-run, 
as  ANSRS  propagates  and  assimilates  users,  the  cost  of  processing 
nonstandard  buys  will  decrease  and  will  ultimately  drive  down  the  total 
weapon  system  support  costs. 

In  other  words,  ANSRS  provides  varying  degrees  of  technical  screening  capability 
at  all  levels,  the  ability  to  consolidate  and  analyze  nonstandard  procurement  data  at  the 
CTA,  and  an  EDI  method  for  reciprocal  communication  between  all  parties.  It  does  not, 
however,  directly  assist  the  requisitioning  activity  in  influencing  the  manufacture,  release, 
and  shipment  of  their  requirements  subsequent  to  contract  award. 

The  ANSRS  prototype  is  a  DOS-based,  menu-driven  application,  which  can  be 
loaded  into  a  personal  computer  (PC).  The  prototype  does  not  interface  with  any  version 
of  the  afloat  shipboard  maintenance/supply/financial  computer  systems  known  as  SNAP 
(Shipboard  Non-tactical  ADP  Program),  and  therefore  does  not  meet  the  precepts  of  R- 
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Supply  and  IT21  9  In  January  1998,  the  CTA  is  scheduled  to  deliver  a  Windows  NT 
version  of  ANSRS  to  the  Navy  Management  Systems  Support  Office  (NAVMASSO)  for 
Technical  Compatibility  Testing  (TCT)  and,  if  it  passes  TCT,  for  inclusion  on 
NAVMASSO’s  Preferred  Products  List  (PPL).  The  final  shipboard  version  could  be 
ready  as  early  as  April  1998  or  as  late  as  June  1998  [Refs.  1 1  and  12].  This  version  will 
interface  with  SNAP.  Until  November  1997,  when  it  was  removed,  a  Customer  Support 
Module  was  available  on  the  Internet,  although  it  could  not  be  used  to  actually  procure 
material. 

4.  Program  Objectives  and  Benefits 

The  following  section  provides  a  brief  overview  of  some  of  the  more  salient 
benefits  ANSRS  is  designed  to  provide  to  the  end-user.  The  System,  Customer  Support 
Module,  Procurement  Activity  Module,  and  Host  Module  objectives  are  listed  in 
Appendix  C  [Ref.  13]. 

a.  Integrated  System 

For  LAN-capable  ships,  the  ANSRS  program  is  installed  throughout,  down 
to  the  division  end-user  and/or  Repair  Parts  Petty  Officer  (RPPO).  The  requirement  can 
be  developed  by  the  end-user  and  submitted  via  the  LAN  for  Supply  Department  review 
and  approval  by  the  Hazardous  Material  Officer,  Department  Head,  Supply  Officer,  and/or 
the  Commanding  Officer  as  required,  based  on  the  requisition  priority  and/or  the  type  of 
material  or  service  required. 


9  Relational  Supply  (R-Supply)  generally  refers  to  ADP  systems  that  are  capable  of  updating  separate 
databases  with  a  single  data  entry  keystroke;  all  supply-related  ADP  equipment  is  connected  into  one 
system.  Information  Technology  21st  Century  (IT21)  is  an  overall  set  of  principles  that  state  that  all  ADP 
equipment  should  be  compatible. 
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b.  Non-Standard  Database  (NSDB) 

The  NSDB  contains  all  of  the  requisitions  submitted  by  ANSRS  customers 
and  procurements  made  by  the  procurement  activities  for  all  unique  cage/part  number 
relationships.  It  is  maintained  by  the  CTA  at  NAYICP-M.  Once  this  data  is  in  the  file, 
and  that  combination  is  required  again,  all  cage/part  number  data — as  well  as  the 
requisitioner’s  default  data — are  pre-loaded  into  the  procurement  document.  Procurement 
history  files  are  also  attached  to  later  facilitate  the  procurement.  NSDB  data  updates  are 
provided  to  all  ANSRS  installations  on  a  regular  basis  via  CD-ROM. 

c,  Reduced  Workload 

ANSRS  automatically  screens  any  requirement  not  resident  within  the 
NSDB  for  hazardous  material  identification  and  NSN  substitutes.  Additionally,  ANSRS 
has  hotkey  connections  to  resident  and  non-resident  reference  resources,  reducing  the 
need  to  maintain  separate  paper/fiche/CD-ROM  libraries.  As  more  items  are  added  to  the 
NSDB,  the  requirement  for  additional  technical  screening  and  research  will  diminish. 
ANSRS  also  allows  requisitions  to  be  batch  processed  and  transmitted. 

d  Enhanced  LRT 

ANSRS  will  reduce  LRT — the  time  interval  between  the  date  of  the 
requisition  and  receipt  of  the  requirement — as  pre-transmission  technical  screening  and 
document  entry  errors  decrease,  thereby  decreasing  the  need  for  the  procuring  activity  to 
request  clarification  and/or  repeat  technical  screening.  Additionally,  transmitting  to  the 
procuring  activity  via  EDI  instead  of  physically  walking  through  the  requirement  decreases 
the  need  for  the  procuring  activity  to  manually  re-enter  procurement  data  into  APADE. 
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Other  LRT  segments,  such  as  manufacturer/vendor  release  time  and  shipping  time,  are  not 
materially  influenced  by  ANSRS. 

E.  MANUAL  PROCUREMENT  PROCESS  FLOW 

The  manual  procurement  process  onboard  a  surface  ship  or  a  submarine  begins 
when  the  end-user  identifies  a  nonstandard  material  or  service  requirement.  It  ends  when 
the  contract  award,  or  buy,  takes  place  (the  time  taken  to  complete  this  process 
determines  Cycle  Time).  Subsequent,  post-award  actions  taken  on  behalf  of  the 
requirement,  such  as  requisition  expediting,  shipment/transportation,  or  receipt  processing, 
are  not  considered  part  of  the  manual  procurement  process  flow  (nor  Cycle  Time)  in  this 
study  because  ANSRS  does  not  automate  those  actions. 

1.  Surface  Ship 

a.  Process  Without  a  Credit  Card 

Once  the  nonstandard  requirement  is  identified,  the  end-user  orders  the 
requirement  on  the  shipboard  maintenance/supply/financial  computer,  one  of  several 
versions  of  the  SNAP  system.  The  requirement  will  either  be  for  a  repair  part  (to  repair  an 
equipment)  or  for  “consumable”  materials  or  services  (e.g.,  equipage,  paint,  vehicle 
rental).  The  latter  are  called  money  value  only  (MVO)  requirements,  which  are  often  of  a 
recurring  nature  and  require  less  technical  screening  (an  important  point  in  this  study). 
Repair  parts  are  ordered  under  a  pre-existing  job  (i.e.,  a  defined  maintenance  action 
resident  within  SNAP);  MVO  requirements  are  ordered  under  a  separate  function.  Next, 
the  end-user  prepares  a  procurement  document  by  hand  that  provides  the  detailed 
information  required  by  the  Supply  Department  to  perform  technical  screening  and  the 
procurement  activity  at  the  FISC  to  make  the  buy,  usually  a  DD  Form  1348-6  or  DD 
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Form  1 149  (Figures.  2.1  and  2.2).  The  document  is  administratively  screened  for  format 
and  content  before  being  technically  screened  for  NSN  substitutes,  HAZMAT  compliance, 
and  authorization  for  shipboard  use.  HAZMAT  must  be  listed  on  the  ship-tailored  Ships 
Hazardous  Materials  List  (SHML);  otherwise,  a  SHML  Feedback  Report  must  be 
submitted  to  the  Type  Commander  (TYCOM).  The  document  then  proceeds  through  an 
approval  sequence  that  includes  the  end-user’s  Department  Head,  the  Supply  Officer  and, 
if  hazardous  (HAZMAT)  or  restricted  material,  the  Hazardous  Materials  Officer  and/or 
the  Commanding  Officer.  The  time  taken  to  complete  the  above  actions  determines  RPT. 
Finally,  the  signed  paper  document  is  delivered  to  the  FISC,  where  it  undergoes  another 
technical  screening  and  is  delivered  to  a  buyer  for  award  using  a  DD  Form  1155  (Figure 
2.3).  The  time  taken  to  complete  these  actions  determines  RST  and  PALT.  At  any  point 
in  this  series  of  events,  incomplete  or  unclear  information  will  result  in  the  return  of  the 
document  to  the  end-user  for  correction  and/or  clarification. 

b.  Process  With  a  Credit  Card 

The  manual  procurement  process  using  a  credit  card  is  the  same  as  that 
described  above  except  that  there  is  no  need  to  deliver  the  document  to  the  FISC.  Once 
the  required  shipboard  approvals  have  been  received,  the  credit  card  holder  can  buy  any 
authorized  repair  part  or  consumable  material  (services  are  prohibited)  from  the 
manufacturer/vendor.  Contacts  with  the  manufacturer/vendor  can  be  done  via  phone,  fax, 
email,  or  in  person.  Written  internal  operating  procedures  must  be  on  file  and  the  Supply 
Department  must  maintain  a  log  of  all  buys  [Ref.  8], 


21 


□ro-n 


1 


=U.S.  GPU:  1986-705- 344 


DOCUMENT 

IDENTIFIER 

routing 

IDENTIFIER 

M 

& 

S 

ITEM  IDENTIFICATION* 

(NSN,  FSCM/Part  No.,  Other) 

UNIT 

OF 

ISSUE 

QUANTITY 

sssss 

FSCM 

PART  NUMBER 

H 

■ 

B 

n 

4 

B 

■3 

B 

B 

9 

ra 

m 

D 

19 

ra 

B 

B 

m 

Ill 

IS 

E9 

m 

m 

E9 

m 

B 

m 

B 

E3 

ES 

ES 

E9 

E9 

El 

d 

E9 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

1 

i 

1 

1 

1 

1 

1 

r~ 

D 

ocur 

i/IENT 

NO. 

(Coni 

-) 

_ 

D 

E 

M 

A 

N 

D 

SUPPLEMENTARY 

S 

1 

G 

N 

A 

L 

FUND 

CODE 

DISTRI¬ 

BUTION 

CODE 

PROJECT  . 

CODE 

PRIORITY 

REQUIRED 

DELIVERY 

DAY  OF 

YEAR 

111 

Hi 

m 

- 1 

DATE  *  SERIAL 

1 

V 

ADDRESS 

ADV 

CO 

hce 

DE 

B 

LANK 

19 

19 

19 

39  !  40 

41 

42 

43 

44 

45 

46 

47 

48 

49 

m 

51 

52 

53 

54 

55 

56 

57 

58 

59 

E9 

61 

62 

63 

64 

65 

66 

67 

68 

69 

wB 

; 

_ 

jjj 

REJECT  CODE 
(FOR  USE 

BY  SUPPLY 
SOURCE  ONLY) 

IDENTIFICATION  DATA 

- 

*1.  MANUFACTURER'S  CODE  AND  PART  NO.  (When  they  exceed  card  columns  8  thru  22) 

H 

n 

19 

E9 

E9 

19 

ES 

a 

B9 

E9 

Pi 

111 

■  65_J 

66 

1 

i 

1 

1 

1 

1 

1 

i 

1 

1 

1 

■ 

■ 

2. 

MANUFACTURER'S  NAME 

3.  MANUFACTURER'S  CATALOG  IDENTIFICATION 


6.  TECHNICAL  MANUAL  NUMBER 


4.  DATE  ( YYMMDD ) 


5.  TECHNICAL  ORDER  NUMBER 


7.  NAME  OF  ITEM  REQUESTED 


8.  DESCRIPTION  OF  ITEM  REQUESTED 


9.  END  ITEM  APPLICATION 


9b.  MAKE 


9c.  MODEL  NUMBER 


10.  REQUISITIONER  (Clear  text  name  and  address) 


9d.  SERIES 


8a.  COLOR 


8b.  SIZE 


9a.  SOURCE  OF  SUPPLY 


9e.  SERIAL  NUMBER 


11.  REMARKS 


DD  Form  1348-6,  FEB  85  Edition  of  Apr  77  may  be  DOD  SINGLE  LINE  ITEM  REQUISITION  SYSTEM 

used  until  exhausted.  DOCUMENT  (MANUAL  -  LONG  FORM) 

S/N  01 02-LF-01 3-2273 


Figure  2.1 


22 


u-O-IO 


*U.S.  GOVERNMENT  PRINTING  OPFICEj  1989-607-293 


SHIPPING  CONTAINER  TALLY 


1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50 


REQUISITION  AND  INVOICE  /  SHIPPING  DOCUMENT 

Form  Approved 

OMB  No.  0704-0246 

Expires  Oct  31.  1991 

Public  reporting  burden  lor  this  collection  of  information  is  estimated  to  average  15  minutes  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and  maintaining  the  data  needed,  and  compieting 
and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information,  including  suggestions  tor  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate 
tor  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,  and  to  the  Office  of  Management  and  Budget,  Paperwork  Reduction  Project  (0704-0246),  Washington,  DC  20503. 

1.  FROM:  (Indude  ZIP  Code) 

SHEET 

NO. 

NO.  OF 
SHEETS 

5.  REQUISITION  DATE 

6.  REQUISITION  NUMBER 

7.  DATE  MATERIAL  REQUIRED  (YYMMDD) 

8.  PRIORITY 

2.  TO:  (Include  ZIP  Code) 

9.  AUTHORITY  OR  PURPOSE 

10.  SIGNATURE 

11a.  VOUCHER  NUMBER  &  DATE  (YYMMDD) 

3.  SHIP  TO-MARK  FOR 

12.  DATE  SHIPPED  (YYMMDD) 

b. 

13.  MODE  OF  SHIPMENT 

14.  BILL  OF  LADING  NUMBER 

15.  AIR  MOVEMENT  DESIGNATOR  OR  PORT  REFERENCE  NO. 

4.  APPROPRIATIONS  SYMBOL  AND  SUBHEAD 

BUR.  CONT.  NO. 

SUBAL- 

AUTHORIZATION 

TRANS. 

PROPERTY  ACCT'G 

COUN- 

LOT 

TYPE 

ACTIVITY 

FEDERAL  STOCK  NUMBER.  DESCRIPTION,  AND  CODING  OF  MATERIEL  AND/OR  SERVICES 

_ (b) 


UNIT 

OF 

ISSUE 

(c) 


QUANTITY 

REQUESTED 


TYPE 

CON¬ 

TAINER 

(I) 


CON¬ 

TAINER 

NOS. 


UNIT  PRICE 

go 


TOTAL  COST 

(i) 


16.  TRANSPORTATION  VIA  MATS  OR  MSTS  CHARGEABLE  TO 


17.  SPECIAL  HANDLING 


Mnl'l  1  IB 

■BjM 

mtjAiinm 

DESCRIPTION 

TOTAL 

WEIGHT 

TOTAL 

CUBE 

-4 -  TOTAL  - ► 

CONTAINERS 
RECEIVED 
EXCEPT  AS 
NOTED 

SHEET  TOTAL 

QUANTITIES 
RECEIVED 
EXCEPT  AS 
NOTED 

DATE  (YYMMDD) 

BY 

GRAND  TOTAL 

POSTED 

DATE  (YYMMDD) 

BY 

20.  RECEIVER'S 

VOUCHER  NO. 

18. 

R 

E  O 
C  F 

A 

P  S 
I  H 


DD  Form  1149,  MAR  89 

S/N  0102-LF -007- 2300 


51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83  84  85  86  87  88  89  90  91  92  93  94  95  96  9798  99  100 
Previous  editions  are  obsolete.  <Navy  0verprint  1989) 

ORIGINAL 


Figure  2.2 


23 


—  . 

9  9 

9 

• 

« 

t  9  «  t 

rU.S.GPO:  1992 -606-841 

e 

9 

0 

o  S3  - 

1  ■  j 

Form  Approved 
OMB  No.  0704-0187 
Expires  Aug  31,  1992 


ORDER  FOR  SUPPLIES  OR  SERVICES 

(Contractor  must  submit  four  copies  of  invoice .) 


Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources.  '  a"d 

maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  cot  ection  of  information, 
inrturtinn  suooestions  for  reducina  this  burden  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway.  Suite  1204,  Arlington,  VA 
^202*4^02,^and* To  ^h^OWic^of^ Management  and  Budget  Paperwork  Reduction  Project  (0704-0187),  Washington.  DC  20503.  Please  DO  NOT  RETURN  your  form  to  either  of  these  addresses. 

Send  your  completed  form  to  the  procurement  official  identified  in  item  6. _ _ _ _ _ _ _ _ 

CONTRACT/PURCH  ORDER  NO.  |  2.  DELIVERY  ORDER  NO.  |  3.  DATE  OF  ORDER  |  4.  REOUISITION.-PURCH  REQUEST  NO.  CHWE^FOR  p 


7.  ADMINISTERED  BY  (If  other  than 


FACILITY  CODE 


10.  DELIVER  TO  FOB  POINT  BY  (Date) 


12.  DISCOUNT  TERMS 


NAME  AND 
ADDRESS 


5.  CERTIFIED  FOR 
NATIONAL  DEFENSE 
UNDER  DMS  REG  1 

DO _ 

8.  DELIVERY  FOB 
DEST 
OTHER 

(See  Schedule  if  other) 
11.  MARK  IF  BUSINESS  IS 


□  SMALL  DISAD¬ 
VANTAGED 
[  WOMEN-OWNED 


13.  MAIL  INVOICES  TO 


15.  PAYMENTWILL  BE  MADE  BY 


DELIVERY  ! 

— 

PURCHASE 

MARK  ALL 
PACKAGES  AND 
PAPERS  WITH 
CONTRACT  OR 
ORDER  NUMBER 


furnish  the  following  on  terms  specified  herein. 


Reference  your  _ ' _ _ _ 

ACCEPTANCE.  THE  CONTRACTOR  HEREBY  ACCEPTS  THE  OFFER  REPRESENTED  BY  THE  NUMBERED  PURCHASE  ORDER  A3  IT  MAY  PREVIOUSLY  HAVE  BEEN  OR  IS  NOW 
MODIFIED,  SUBJECT  TO  ALL  OF  THE  TERMS  AND  CONDITIONS  SET  FORTH,  AND  AGREES  TO  PERFORM  THE  SAME. 


_ _ ,  NAME  OF  CONTRACTOR  SIGNATURE 

I : _ |  |f  this  box  is  marked  niier  must  sign  Acceptance  and  return  the  following  number  of  copies: 


r«r»r,’,  1 1  ? » i  i  ■  f.i  j 


APPROPRIATE  MBOL 
AND  SUBHEAD 


SCHEDULE  OF  SUPPLIES/SERVICE 


TYPED  NAME  AND  TITLE 


DATA 

PROPERTY  COUN- 
ACC'T  ACT  Y  TRY  _ _ 


20.  QUANTITY  21.  | 

ORDERED/  UNIT 
ACCEPTED* 


*  If  quantity  accepted  by  the  Government  is  same  as  24.  UNITED  STATES  OF  AMERICA 
quantity  ordered,  indicate  by  X.  If  different,  enter 
actual  quantity  accepted  below  quantity  ordered  and 

encircle.  _ BY  _ 

26.  QUANTITY  IN  COLUMN  20  HAS  BEEN  2 

□  INSPECTED  FI  RECEIVED  fl  ACCEPTED.  AND  CONFORMS  TO  THE 

[ — 1  * — 1  CONTRACT  EXCEPT  AS  NOTED  f 


CONTRACTING /ORDERING  OFFICER  DIFFERENCES) 


28.  O.O.  VOUCHER  NO. 


—  —  CONTRACT  EXCEPT  AS  NLnfcu  Q  pARTIAL  32.  PAID  BY 

|  |  FINAL 

DATE  SIGNATURE  OF  AUTHORIZED  GOVERNMENT  REPRESENTATIVE  31  PAYMENT 


36:  I  certify  this  account  is  correct  and  proper  for  payment. 

DATi  SIGNATURE  AND  TITLE  OF  CERTIFYING  OFFICER 

37.  RECEIVED  AT  I  38.  RECEIVED  BY  I  39  DAre  1 


|  |  COMPLETE 

|  |  PARTIAI 

i  |  FINAL 


INITIALS  I 

33.  AMOUNT  VERIFIED  CORRECT  FOR 


34.  CHECK  NUMBER 


35.  BILL  OF  LADING  NO. 


DD  Form  1155  (8PT),  MAY  90 


DArE  RECEIVED  40.  TOTAL  CONTAINERSj  41.  S-R  ACCOUNT  NUMBER  42.  S/R  VOUCHER  NO. 


Previous  editions  are  obsoiete.  S/N  01 02-LF-01 1-4700 


Figure  2.3 


24 


2. 


Submarine 


The  identification,  ordering,  procurement  document  preparation,  and  approval 
process  for  a  submarine  is  the  same  as  that  of  a  surface  ship.  However,  Supply  Officers  of 
submarines  generally  do  not  carry  their  own  credit  card  and  submit  all  of  their  nonstandard 
procurement  requirements  to  the  SLSC-PH. 10  Additionally,  the  vast  majority  of 
procurements  onboard  submarines  are  MVO  requirements.  Storekeepers  (SK)  assigned  to 
USS  KEY  WEST  (SSN  722)  could  not  recall  ever  ordering  a  nonstandard  repair  part 
(although  they  knew  how)  [Ref.  14].  The  SUBPAC  Force  Storekeeper  recalled  ordering 
only  one  nonstandard  repair  part  in  four  years  aboard  his  last  submarine  and,  of  the 
approximately  25  submarines  he  has  inspected  in  his  current  position,  has  seen  “very  few” 
[Ref.  15]. 

A  short  tangent  is  appropriate  here  to  discuss  the  underlying  causes  of  low 
nonstandard  repair  part  procurements  by  submarines:  configuration  management  and 
demand  reporting.  Configuration  management  basically  consists  of  validating  actual 
onboard  equipment  against  those  listed  in  the  Weapons  System  File  (WSF)  located  at 
NAVICP-M.  Accurate  configuration  validation  and  reporting  leads  to  accurate  onboard 
NSN  repair  part  support.  Accurate  and,  importantly,  complete  demand  reporting  leads  to 
more  NSN  assignments  to  nonstandard  repair  parts  that  are  used  with  any  frequency.  If 
done  properly,  the  above  actions  result  in  less  reliance  on  nonstandard  repair  parts, 
although  this  situation  could  change  in  the  future  with  an  increased  use  of  CANDI. 
SUBPAC  submarines  are  able  to  attain  a  configuration  accuracy  in  excess  of  93  percent 
[Ref.  16]  because  they  are  able  to  devote  the  time  necessary  to  conduct  accurate 

10  Some  SUBLANT  submarines  maintain  their  own  credit  card  whereas  none  do  in  SUBPAC  as  yet. 
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configuration  management  and  are  supported  by  a  database  that  records  almost  all  of  their 
demands. 

Interposed  between  the  submarine  and  FISC-PH  is  SLSC-PH.11  Located 
in  the  same  building  as  FISC-PH,  the  goals  of  SLSC-PH  are  to  reduce  the  workload  of  the 
afloat  submarine  Supply  Department  and  increase  the  submarine’s  supply  readiness. 
SLSC-PH  logs  the  requirement,  performs  a  procurement  document  accuracy  check  and  an 
additional  technical  screen,  then  either  makes  the  buy  (for  credit  card  purchases)  or  walks 
the  document  to  the  FISC  buyer.  After  the  buy  is  completed,  all  procurement  data  is  input 
into  the  Integrated  Submarine  Information  System  (ISIS)  for  recording  in  the  Submarine 
Logistics  Data  Base  (SLDB),  a  centralized  demand  reporting  database  maintained  at 
King’s  Bay,  Georgia  [Ref.  17],  The  time  taken  to  deliver  the  document  to  SLSC-PH,  and 
the  processing  time  taken  by  SLSC-PH  prior  to  making  a  credit  card  buy  or  the 
document’s  acceptance  at  FISC-PH,  are  included  in  RST. 

F.  CHAPTER  SUMMARY 

The  Navy  classifies  material  into  two  categories:  standard  and  nonstandard. 
Services  are  always  “nonstandard.”  If  available,  standard  material  must  be  procured 
before  nonstandard  sources  can  be  contemplated.  There  are  numerous  rules  and 
regulations  governing  the  procurement  of  nonstandard  materials  and  services.  It  is 
important  for  the  end-user  to  understand  when  and  how  nonstandard  material  or  services 
can  be  procured.  This  study  uses  the  term  “Cycle  Time”  to  measure  the  interval  between 
the  time  the  end-user  identifies  a  nonstandard  requirement  and  the  time  the  contract  for 
that  requirement  is  awarded.  Cycle  Time  is  broken  down  into  three  segments:  RPT,  RST, 

11  Similar  activities  service  other  submarine  bases. 
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and  PALT.  EC/EDI  methods  are  used  to  enhance  the  exchange  of  data.  Legislation 
requires  the  use  of  these  methods  as  a  way  to  produce  process  efficiencies,  and  they  play  a 
key  role  in  efforts  to  reduce  Cycle  Time. 

ANSRS  was  designed  to  automate  and  streamline  the  nonstandard  procurement 
process.  It  evolved  from  several  automated  systems,  principally  TSES  and  SPEED. 
ANSRS  provides  the  end-user  with  an  integrated  system  that  will  reduce  workload  and 
reduce  the  time  it  takes  to  receive  nonstandard  material  and  services.  This  chapter  closes 
with  a  broad  presentation  of  the  manual  nonstandard  procurement  processes  common  to 
surface  ships  and  submarines.  Chapter  III  provides  the  reader  more  detail  on  the  manual 
process  and  quantifies  both  the  manual  and  ANSRS  nonstandard  procurement  processes. 
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m.  PROCUREMENT  AND  ANSRS 


Unlike  surface  vessels,  which  have  the  ability  to  replenish  stores  at  sea,  and  shore 
stations,  which  are  fixed  in  place,  submarines  must  receive  all  of  their  requirements  before 
getting  underway.  This  results  in  an  urgency  that  has  spurred  the  submarine  community  to 
invest  in  and  develop  logistics  procedures  generally  considered  superior  to  those  employed 
by  surface,  air,  and/or  land-based  fleet  communities.  Since  the  submarine  community  is 
somewhat  logistically  different,  implementation  of  ANSRS  within  the  submarine 
community  may  also  be  somewhat  different.  This  chapter  provides  background  on  the 
limited  implementation  of  ANSRS  within  the  Navy  and  a  brief  overview  of  the  ANSRS 
Afloat  Customer  Module  (ACM)  prototype.  Additionally,  the  manual  procurement 
process  flow  will  be  discussed,  diagrammed,  and  quantified,  as  will  the  ANSRS 
procurement  process  flow  for  surface  ships  and  FISCs.  To  date,  ANSRS  has  not  been 
implemented  onboard  any  submarine. 

A.  ANSRS  IMPLEMENTATION 
1.  Background 

a.  Strategy 

The  implementation  strategy  for  the  DOS-based  ANSRS  prototype  initially 
called  for  installing  a  Procurement  Activity  Module  at  each  FISC,  and  a  Customer 
Support  Module  onboard  two  afloat  customers  of  each  FISC.  The  ongoing  development 
of  the  Windows  NT  version  has  ended  further  installations  until  the  newer  version  is 
completed. 
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b.  Schedule 

The  first  prototype  installations,  at  FISC  Norfolk  and  onboard  USS 
SAIPAN  (LHA  2),  were  completed  in  March  1996.  The  last  prototypes  were  installed  in 
August  1997.  Prototype  versions  are  installed  at  1 1  FISCs/FISC  satellites,  14  ships 
(including  two  carriers),  three  Naval  Air  Stations  (NAS),  two  Ship  Repair  Facilities 
(SRF),  and  two  Fleet  Activities  (FLEACT).  ANSRS  is  to  be  installed  at  all  Navy 
customer  activities,  although  the  installation  schedule  has  not  been  promulgated.  See 
Appendix  D  for  a  list  of  sites  implemented. 

2.  Responsibilities 

u.  Prototype  Version 

In  addition  to  assuming  developmental  responsibility  for  the  ANSRS 
prototype,  the  CTA  was  responsible  for  its  deployment  to  shore  activities  and  prototype 
ships,  including  aircraft  carriers.  The  CTA  is  also  responsible  for  evaluating  ANSRS 
prototype  performance  [Ref.  12], 

b.  Windows  NT  Version 

Responsibility  for  deploying  the  Windows  NT  version  of  ANSRS  to  afloat 
units,  including  aircraft  carriers,  will  belong  to  NAVMASSO,  under  the  direction  of 
NAVSUP  43.  Shore  activity  implementation  responsibilities  will  remain  with  the  CTA 
[Refs.  11  and  12]. 

c.  “ANSRS-Air” 

Although  not  assigned  any  implementation  responsibilities,  it  is  important 
to  note  here  that,  because  of  differing  organizational  responsibilities  and  capabilities, 
NAVTCP  Philadelphia  (NAVICP-P)  will  retain  the  personnel  responsible  for  the  deep 
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technical  screening  (see  next  paragraph)  and  compilation  of  aviation-related  nonstandard 
procurements.  Procurement  data  will,  however,  be  passed  to  NAVICP-M  for  inclusion  in 
the  NSDB.  Although  the  NAVICPs  may  never  combine  personnel  at  one  central  location, 
ANSRS  should  eventually  provide  a  single  “face  to  the  fleet”  [Ref.  12]. 
cL  Deep  Technical  Screening 

Deep  technical  screening  refers  to  the  process  of  validating  nonstandard 
repair  part  procurements  initiated  by  the  end-user  against  the  end-user  activity’s  Weapons 
System  File  (WSF)  at  either  NAVICP-M  or  NAVICP-P.  Results  of  deep  screening  could 
range  from  a)  inclusion  of  the  nonstandard  repair  part  in  the  end-user’s  Coordinated 
Shipboard  Allowance  List  (COSAL),  Aviation  Consolidated  Allowance  List  (AVCAL), 
Coordinated  Shore  Base  Allowance  List  (COSBAL),  or  Shore  Consolidated  Allowance 
List  (SHORCAL);  to  h)  triggering  a  complete  validation  check  of  the  end-user’s 
equipment  configuration. 

B.  PROTOTYPE  AFLOAT  CUSTOMER  MODULE 

1.  Installation  and  Setup 

The  ACM12  consists  of  four  3.5  diskettes  and  requires  17.84  MB  of  hard  drive 
space.  It  can  operate  in  three  types  of  PC  environments:  standalone,  LAN  Server,  or 
LAN  Workstation.  Installation  and  setup  were  completed  in  less  than  15  minutes. 
Installation  instructions  were  easy  to  comprehend.  Setup  instructions  were  less  explicit, 
but  not  overly  complex. 


12  NAVSUP  PUB  700  (Jan  95).  NSN  0530-LP-190-2800 
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2.  Operation 

After  logging  on  to  the  ACM,  the  user  can  select  a  course  of  action  from  one  of 
five  menus:  Requisition,  Database,  Approval,  Security,  and  Help.  Except  for  the  Help 
menu,  each  menu  consists  of  several  functions. 13  There  are  additional  “hotkey”  functions 
used  to  access  reference  files,  either  resident  in  the  computer’s  hard  drive  or  imported  via 
disk.  The  ACM  allows  the  user  to  either  perform  a  technical  screening  or  construct  a 
procurement  document.  Technical  screening  was  easy  to  accomplish;  the  logic  paths  were 
easy  to  follow  and  the  sources  were  easy  to  access.  The  ACM  is  good  at  prompting  the 
user  for  missing  information  required  in  the  data  tables.  The  menus  were  easy  to 
understand  and  the  ACM  appears  to  incorporate  the  Customer  Support  Module  objectives 
contained  in  Appendix  C  [Ref.  13]. 

C.  MANUAL  AND  ANSRS  PROCUREMENT  PROCESS  FLOWS 

In  this  section,  manual  and  ANSRS  procurement  process  flows  are  discussed  and 
diagrammed  using  flow  charts.  Time  is  quantified  to  the  greatest  possible  extent,  given 
the  organization  and  effectiveness  of  different  activities,  and  presented  as  a  value  range. 
The  ranges  show  approximate  values  that  were  derived  from  averaging  questionnaire 
responses  (see  Appendix  E)  and  data  obtained  via  other  means,  such  as  interviews. 
Pertinent  comments  from  interviews  and  questionnaire  responses  are  include  in  the 
discussion  as  noted  in  brackets  and  [italics].  For  convenience,  relevant  flow  charts 
(Figures  3.1  through  3.5)  are  located  at  the  end  of  this  section. 


13  The  Help  menu,  in  the  author’s  view,  is  misnamed.  It  provides  no  help  topic  selections,  but  instead 
only  the  names  of  the  software  designers/programmers  and  some  phone  numbers  to  call  for  technical 
support. 
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1.  Manual  Process  Flow  Through  Surface  Ship  to  FISC  and  Buyer 

The  following  manual  procurement  process  flow  discussions  and  depictions  are 
derived  from  telephone  interviews  with  Supply  Department  personnel  assigned  to  various 
Naval  Surface  Forces  Pacific  (SURFPAC)  ships,  personal  and  telephone  interviews  with 
FISC  personnel,  through  questionnaire  responses,  and  the  author’s  eight  years  of 
experience  aboard  USS  WHIPPLE  (FF  1062),  USS  FIFE  (DD  991)  and  as  a  SURFPAC 
staff  officer.  [Ships  reported  initiating  15  to  90  nonstandard  procurements  a  month,  or 
0.5  to  3  per  day.  Approximately  75  percent  were  credit  card  purchases  for  those 
commands  using  a  credit  card.  Depending  on  the  urgency  and  type  of  the  requirement, 
RPTwas  completed  in  about  one  hour  to  over  one  day  (see  Table  3. 1).  Depending  on  the 
urgency  of  the  requirement,  method/type  of procurement,  and  mode  of  delivery  to  the 
FISC  (if  not  a  credit  card  buy),  RST/PALT  took  1  hour  to  25  days  (see  Table  3.2).  Total 
Cycle  Time  ranged  from  about  2  hours  to  26  days  (see  Table  3.3).  ] 

Some  steps  in  the  manual  procurement  process  flow  are  conducted  differently  by 
separate  ships  although  the  same  outcome  is  achieved.  For  instance,  some  ships  require 
the  end-user  to  order  an  MVO  requirement  in  SNAP  and  fill  out  a  procurement  document 
before  the  SK  will  conduct  technical  screening.  Others  require  only  a  locally  developed 
worksheet  that  is  used  by  the  SK  to  conduct  technical  screening;  it  is  the  SK  who  inputs 
the  MVO  requirement  into  SNAP  and  fills  out  the  procurement  document.  Sometimes  the 
Commanding  Officer  will  not  sign  a  document  until  the  Supply  Officer  does;  usually, 
however,  the  Supply  Officer  signs  last.  Sometimes  the  SK  walks  the  document  to  the 
FISC,  sometimes  the  end-user  does.  Since  it  is  impractical  to  depict  all  possible 
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variations,  the  methods  most  commonly  employed  by  those  included  in  the  author’s 
research  are  discussed  and  diagrammed  here. 

a.  Manual  Requisition  Preparation  Time  (RPT) 

Manual  RPT  is  diagrammed  in  Figure  3.1.  RPT  begins  when  the  end-user 
identifies  a  requirement  through  initial  research  that  may  include  technical  manuals, 
drawings,  microfiche/film/CD-ROM  libraries,  discussions  with  manufacturers  or  vendors, 
and  personal  records.  The  requirement  will  either  be  for  repair  parts  (to  repair  an 
equipment)  or  for  “consumable”  material  or  services  (e.g.,  equipage,  paint,  vehicle  rental). 
The  latter  are  called  money  value  only  (MVO)  requirements.  If  the  requirement  is  for  a 
repair  part,  the  end-user  will  complete  the  following  sequence  of  events:  1)  open  a 
maintenance  job  in  SNAP  (if  none  already  exists);  2)  search  the  equipment’s  Allowance 
Parts  List  (APL)  resident  in  SNAP  for  an  NSN  match  if  only  the  cage  and  part  number  are 
known;  and  3)  order  the  part  in  SNAP.  If  an  MVO  requirement,  it  is  ordered  through  a 
different  function  in  SNAP.  No  maintenance  job  is  opened  or  needed.  Either  way,  the 
end-user  then  manually  prepares  a  procurement  document  and  delivers  it  to  an  SK  for 
technical  screening.  [Initial  research  for  repair  parts  took  from  15  to  60  minutes, 
depending  on  the  library  databases  that  needed  to  be  searched  and  whether  a 
manufacturer  or  vendor  was  contacted.  Initial  research  for  MVO  requirements  ranged 
from  five  minutes  if  of  recurring  nature  to  one  hour  if  a  manufacturer  or  vendor  was 
contacted.  Ordering  a  repair  part  in  SNAP  took from  30  to  45  minutes,  most  of  which 
was  spent  opening  the  requisite  job  and  conducting  an  APL  search.  Ordering  MVO 
requirements  took  two  to  five  minutes.  Document  preparation  and  delivery  to  the  SK 
took  from  10  to  30  minutes.] 
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The  SK  first  reviews  the  document  for  errors  and  completeness  of  required 
data.  If  the  requirement  is  for  a  repair  part  or  consumable  material  the  SK  will  check  the 
FEDLOG  to  determine  if  there  exists  an  NSN  substitute  and  the  SHML  (and/or  other 
databases)  to  determine  if  the  material  is  hazardous  or  otherwise  restricted.  Requirements 
for  services  will  be  checked  against  regulations  delineating  authorized  service 
procurements.  This  process  is  known  as  administrative  and  technical  screening. 
[Administrative  screening  took  one  to  two  minutes.  Technical  screening  took  15  to  60 
minutes,  depending  on  whether  a  manufacturer  or  vendor  was  queried,  whether  the 
material  was  hazardous  or  restricted,  etc.] 

After  the  screening  is  completed,  the  end-user  or  SK  walks  the  document 
through  the  Department  Head,  the  Hazardous  Material  Officer  (for  HAZMAT),  the 
Commanding  Officer  (for  restricted  materials  and/or  HAZMAT),  and  the  Supply  Officer. 
If  the  material  is  hazardous  but  not  listed  in  the  SHML,  a  SHML  feedback  report  is 
submitted.  After  obtaining  the  requisite  approvals,  the  document  is  returned  to  the  SK 
who  then  changes  the  end-user’s  SNAP-generated  request  number  to  a  requisition 
number.  After  the  requisition  number  is  transcribed  onto  the  document,  the  document  is 
ready  for  delivery  to  the  procurement  activity.  Failure  to  obtain  the  Commanding 
Officer’s  signature  for  hazardous  or  restricted  materials  could  result  in  the  cancellation  of 
the  requirement.  RPT  is  identical  for  credit  card  purchases.  [Approvals  took  anywhere 
from  30  minutes  to  a  day,  depending  on  the  nature  of  the  requirement  (e.g.  HAZMAT) 
and  the  availability  of  the  Department  Head,  Commanding  Officer,  etc.  It  took  two  to 
four  minutes  to  assign  a  requisition  number.] 
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Duration 
(repair  parts) 

15  min  -  1  hr _ 

30  -  45  min _ 

10  -  30  min _ 

1-2  min _ 

15  min  -  1  hr _ 

30  min  -  24  hrs 

I  Assign  requisition  number _ I  2  -  4  min _ 

Total  RPT  1.72  -  27.35  hrs 

Table  3.1  Manual  RPT  for  Ships 

b.  Manual  Requisition  Submission  Time  (RST)  and  Manual 
Procurement  Administrative  Lead  Time  (PALT) 

Manual  RST  and  manual  PALT  for  procurement  documents  that  are 
delivered  to  the  procurement  activity/FISC  for  award  are  diagrammed  in  Figure  3.2.  RST 
and  PALT  for  credit  card  buys  is  too  simple  a  flow  to  diagram,  as  will  become  evident  in 
the  preceding  paragraphs. 

RST  is  the  interval  between  the  moment  RPT  is  completed  to  the  moment 
the  procurement  document  is  accepted  by  the  procurement  activity.  “Acceptance”  occurs 
only  when  FISC  Customer  Service,  FISC  Technical,  and  the  FISC  buyer  are  satisfied  that 
the  document  is  administratively  complete  and  provides  sufficient  information  to  make  the 
buy.  Delays  caused  by  requests  for  additional  data  are  included  in  RST  (see  Appendix  F 
for  top  reasons  why  requisitions  are  returned  to  the  ship).  RST  is  almost  nonexistent  in 
credit  card  purchases  as  these  purchases  are  never  delivered  to  the  FISC;  after  the 
requisition  number  is  assigned,  the  document  is  accepted  by  the  buyer  (i.e.,  credit  card 
holder,  likely  the  same  SK).  [Ships  reported  hand-delivering  or  mailing  3  to  15 


"Task 

Initial  research _ 

Order  in  SNAP _ 

Prepare  procurement  document 
and  deliver  to  SK 


Approvals 


SK  administrative  screenin 
SK  technical  screening 


Duration 

(MVO) 

5  min  -  1  hr 
2-5  min _ 

10 -30  min 

1  -2  min _ 

15  min  -  1  hr 
30  min  -  24  hrs 

2-4  min _ 

1.08  -  26.68  hrs 


nonstandard  procurement  documents  to  the  procurement  activity/FISC  a  month.]  The 
document  is  first  submitted  to/received  at  FISC  Customer  Service  where  it  is 
administratively  screened.  The  document  is  then  forwarded  to  FISC  Technical  where  the 
requirement  is  again  technically  screened  for  NSN  substitutes,  HAZMAT  compliance,  and 
authorization  for  shipboard  use.  Any  data  inconsistencies  or  omissions  are  resolved  with 
the  ship.  After  technical  screening,  it  is  forwarded  to  the  FISC  buyer  for  contract  award. 
[Depending  on  the  urgency  and  mode  of  delivery  to  the  FISC,  RST  was  completed  in  45 
minutes  to  ten  days.  RST for  credit  card  buys  took  less  than  one  minute.] 

PALT  is  the  interval  between  the  moment  the  procurement  document  is 
accepted  by  the  buyer  to  the  moment  the  contract  is  awarded;  in  other  words,  it  is  the 
measure  of  the  time  it  takes  the  buyer  to  make  a  buy.  PALT  standards  vary  among 
different  procurement  activities.  PALT  for  credit  card  purchases  is  assigned  to  the  SK 
who  prepares  the  DD  Form  1155  and  contracts  with  a  local  vendor  for  the  repair  part  or 
consumable  material  requirement.  [Depending  on  the  urgency,  PALT  at  the  FISC  took 
one  hour  to  15  days.  PALT for  credit  card  buys  made  by  the  ship  took  one  to  1.5  hours.] 


Process 

Hand-delivered 

FISC 

RST 

45  min  -  1.5  hrs 

3-10  days 

PALT 

1  hr  -  1 5  days 

1  hr  - 15  days 

Total  RST/PALT  at  FISC 

Credit  card  (onboard  a  ship) 

RST 

<  1  min 

N/A 

PALT 

1  -  1.5  hrs 

N/A 

Total  RST/PALT  on  ship 

1  - 1.5  hrs 

N/A 

Table  3.2  Manual  RST  and  PALT  (Ships  to  FISC) 
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Process  Segment 

Duration 

RPT 

1.08  hrs- 27.35  hrs 

RST 

<  1  min  -  10  days 

PALT 

1  hr  -  1 5  days 

Total  Cycle  Time 

2  hrs  -  26  days 

Table  3.3  Manual  Cycle  Time  (Ship  to  FISC) 

2.  Manual  Process  Flow  Through  Submarine  to  SLSC  to  FISC  and 
Buyer 

The  following  manual  procurement  process  flow  discussions  and  depictions  are 
derived  from  the  author’s  personal  interviews  with  the  Supply  Officer  and  Leading  SK 
assigned  to  USS  KEY  WEST  (SSN  722),  homeported  in  Pearl  Harbor,  the  officers  in 
charge  of  the  Submarine  Logistics  Support  Center,  Pearl  Harbor  Detachment  (SLSC-PH), 
the  SUBPAC  Force  Supply  Officer  and  Force  Storekeeper,  and  FISC-PH  personnel. 

Submarines  submit  most,  if  not  all,  of  their  nonstandard  requisitions  while  in  port. 
All  are  hand-dt  ered  to  the  SLSC-PH  (or  equivalent  in  other  ports).  To  date,  SUBPAC 
submarines  do  not  maintain  their  own  credit  cards.  Submarines,  in  the  interest  of  stealth, 
keep  electronic  transmissions  to  a  minimum  while  underway.  [Submarines  reported 
initiating  15  nonstandard  procurements  a  month,  or  0.5  per  day.  Micro-purchases 
accounted  for  99  percent  and,  of  these,  95  percent  were  recurring  MVO  requirements. 
RPTwas  equal  to  that  of  ship  MVO  RPT,  about  one  hour  to  one  day  (see  Table  3.1,  MVO 
column).  Depending  on  the  urgency  of  the  requirement,  and  method  or  type  of 
procurement,  RST/PALT  took  2  hours  to  10  days  (see  Table  3.4).  Total  Cycle  Time 
ranged from  2.17  hours  to  11  days  (see  Table  3.5).  ] 
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a.  Manual  Requisition  Preparation  Time  ( RPT) 

RPT  is  the  same  as  that  onboard  a  surface  ship.  Figure  3.1  is  equally 
applicable  to  submarines.  However,  99  percent  of  nonstandard  requirements  ordered  by  a 
submarine  are  MVO  requirements  and  are  usually  of  a  recurring  nature  and,  thus,  require 
less  technical  screening.  [Initial  research  for  MVO  requirements  ranged from  five 
minutes  if  of  a  recurring  nature  to  one  hour  if  a  manufacturer  or  vendor  was  contacted. 
Ordering  MVO  requirements  took  two  to  five  minutes.  Document  preparation  and 
delivery  to  the  SK  took  from  10  to  30  minutes.  Administrative  screening  took  one  to  two 
minutes.  Technical  screening  took  15  to  60  minutes,  depending  on  whether  the 
manufacturer  or  vendor  was  again  contacted,  whether  the  material  was  hazardous  or 
restricted,  etc.  Approvals  took  anywhere  from  30  minutes  to  a  day,  depending  on  the 
nature  of  the  requirement  (e.g.  HAZMAT)  and  the  availability  of  the  Department  Head, 
Commanding  Officer,  etc.  It  took  two  to  four  minutes  to  assign  a  requisition  number.] 

b.  Manual  Requisition  Submission  Time  (RST)  and  Manual 
Procurement  Administrative  Lead  Time  (PALT) 

Interposed  between  the  submarines  stationed  in  Pearl  Harbor  and  FISC-PH 
is  the  SLSC-PH,  which  is  located  in  the  same  building  as  the  FISC.  All  SLSC-PH 
branches  (i.e..  Customer  Service,  Technical  Section,  and  the  credit  card  buyers)  are 
located  in  the  same  open  workspace.  Manual  RST  and  PALT  for  submarines  are 
diagrammed  in  Figure  3.3. 

The  requisition  is  first  submitted  to  Customer  Service,  where  the  document 
is  logged  in  and  administratively  screened.  It  is  then  forwarded  to  the  Technical  Section 
where  the  requirement  is  again  technically  screened  for  NSN  substitutes,  HAZMAT 
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compliance,  and  authorized  shipboard  use.  Any  inconsistencies  or  omissions  are  resolved 
with  the  submarine,  and  the  resultant  delays  are  included  in  RST.  After  technical 
screening,  the  requirement  is  walked  to  either  the  FISC  buyer  (because  a  second  technical 
screening  is  conducted  by  the  SLSC-PH,  the  document  bypasses  FISC  Technical)  or,  if  a 
credit  card  purchase,  to  one  of  three  SLSC-PH  credit  card  holders.  [RST  was  completed 
in  45  minutes  to  1.5  hours.  There  is  no  significant  difference  between  RST  involving 
credit  card  buyers  or  FISC  buyers.] 

PALT  for  credit  card  purchases  is  assigned  to  the  SLSC-PH  buyer  who 
prepares  the  DD  1155  and  contracts  with  the  local  vendor  for  the  consumable  material 
requirement.  PALT  for  other  types  of  procurements  are  assigned  to  the  FISC  buyer.  The 
close  proximity  of  SLSC-PH  to  the  FISC  buyer  ensures  that  critical  requirements  are 
procured  rapidly.  Low-priority  requirements  are  not  so  forcefully  expedited  by  SLSC-PH, 
but  are  expedited  nonetheless.  Copies  of  contracting  forms  are  maintained  by  the  SLSC- 
PH  in  addition  to  those  mailed  to  the  submarine.  [Depending  on  the  urgency,  PALT for 
credit  card  buys  took  20  minutes  to  1.5  hours.  PALT  at  the  FISC  took  1  hour  to  10 
days.] 


Process  Segment 

Duration 

RST  (hand-delivered) 

45  min  -  1.5  hrs 

PALT  (credit  card  buy) 

20  min  -  1.5  hrs 

PALT  (FISC) 

1  hr  - 10  days 

Total  RST/PALT 

2  hrs  -  10  days 

Table  3.4  Manual  RST  and  PALT  (Submarine  to  SLSC  to  FISC) 
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Process  Segment 

Duration 

RPT 

1.08  hrs  -  26.65  hrs 

RST 

45  min  - 1.5  hrs 

PALT 

20  min  -  10  days 

Total  Cycle  Time 

2.17  hrs  -  11  days 

Table  3.5  Cycle  Time  (Submarine  to  SLSC  to  FISC) 

3.  ANSRS  Process  Flow  Through  Surface  Ship  to  FISC  and  Buyer 

The  following  ANSRS  procurement  process  flow  discussions  and  depictions  are 
derived  from  questionnaire  responses  and  telephone  interviews  with  supply  personnel  from 
activities  installed  with  the  ANSRS  prototype,  including  ships  and  FISCs.  Telephone 
interviews  were  also  conducted  with  ANSRS  Program  personnel  at  NAVSUP  and 
NAVTCP-M.  [Ships  reported  initiating  15  to  90  nonstandard  procurements  a  month,  or 
0.5  to  three  a  day.  Approximately  75  percent  were  credit  card  purchases  for  those 
commands  using  a  credit  card.  Depending  on  the  type  and  urgency  of  the  requirement, 
RPT  was  completed  in  52  minutes  to  more  than  one  day  (see  Table  3.6).  Again, 
depending  on  the  type  and  urgency  of  the  requirement,  RST/PALT  took  30  minutes  to  2.5 
hours  (see  Table  3. 7).  Total  Cycle  Time  ranged from  1.37  hours  to  more  than  a  day  (see 
Table  3.8).] 

Figure  3.4  is  similar  to  the  manual  procurement  process  flow  diagrammed  in 
Figure  3. 1  as  ANSRS  does  not  actually  eliminate  any  steps,  but  instead  automates  them. 
Figure  3.4  assumes  an  interface  between  SNAP  and  ANSRS  on  a  LAN-capable  ship.  The 
dotted  lines  indicate  those  steps  automated  by  ANSRS.  Likewise,  Figure  3.5  is  similar  to 
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Figure  3.2  and  assumes  neither  EDI  nor  interface  problems  between  the  ship  and  FISC  and 
within  the  FISC. 

a .  ANSRS  Requisition  Preparation  Time  (RPT) 

ANSRS  RPT  is  diagrammed  in  Figure  3.4.  RPT  begins  when  the  end-user 
identifies  a  requirement  through  an  initial  research  that  may  include  technical  manuals, 
drawings,  microfiche/film/CD-ROM  libraries,  discussions  with  manufacturers,  and 
personal  records.  Either  a  repair  part  or  an  MVO  requirement  will  be  eventually  ordered. 
ANSRS  is  useful  as  a  research  tool  in  this  step  for  identifying  MVO  cage/part  numbers  for 
items  such  as  paint.  If  the  requirement  is  for  a  repair  part,  the  end-user  will  open  a 
maintenance  job  in  SNAP  and  search  the  equipment’s  APL  for  an  NSN  match.  If  no 
match  is  found,  the  end-user  will  access  the  ANSRS  program  and  order  the  requirement 
by  cage  and  part  number.  MVO  requirements  can  also  be  ordered  by  accessing  the 
ANSRS  program  as  no  maintenance  job  is  opened  or  needed.  ANSRS  will  automatically 
check  for  NSN  substitutes  on  those  cage/part  number  relationships  resident  within  the 
NSDB;  the  FEDLOG  can  also  be  accessed  through  ANSRS.  The  end-user  next  selects  a 
pr '  mrement  document  format  and  fills  in  the  required  information.  If  the  cage/part 
number  relationship  is  resident  within  the  NSDB,  the  information  will  already  be  provided 
on  the  document.  The  document  is  then  ready  for  an  online  technical  screening  by  an  SK. 
[Initial  research  for  repair  parts  or  MVO  requirements  ranged from  two  minutes  to  one 
hour  depending  on  whether  the  cage/part  number  relationship  was  resident  in  ANSRS 
and/or  a  manufacturer  or  vendor  was  contacted.  Ordering  a  repair  part  took  20  to  45 
minutes,  most  of  which  was  spent  opening  the  requisite  job  cmd  conducting  an  APL 
search,  and  again  depending  on  whether  the  cage/part  number  relationship  was  resident 
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in  ANSRS.  Ordering  MVO  requirements  took  two  to  five  minutes.  Document  preparation 
took  from  five  to  ten  minutes.] 

The  SK  accesses  the  document  and  reviews  it  for  completeness  and  errors. 
If  the  requirement  is  for  a  repair  part  or  consumable  material  the  SK  will  access  the 
FEDLOG,  the  SHML,  and/or  other  online  databases  to  check  for  NSN  substitutes  and 
determine  if  the  material  is  hazardous  or  otherwise  restricted.  Requirements  for  services 
will  be  checked  against  regulations  delineating  authorized  service  requirements,  some  or 
all  of  which  may  be  online.  [Administrative  screening  took  one  to  two  minutes.  Technical 
screening  took  ten  minutes  to  one  hour  depending  on  whether  a  manufacturer  or  vendor 
was  contacted,  whether  the  material  was  hazardous  or  restricted,  and  whether  FEDLOG 
and  other  databases  were  online  ANSRS. ] 

After  the  screening  is  completed,  the  document  is  ready  for  a  series  of 
online  approvals  by  all  necessary  personnel  including  the  Hazardous  Material  Officer  (for 
HAZMAT),  the  Department  Head,  the  Commanding  Officer  (for  restricted  material  and/or 
HAZMAT),  and  the  Supply  Officer.  If  the  requirement  is  urgent,  the  end-user  may  have 
to  “urge”  these  officers  to  access  their  computers,  a  potential  bottleneck,  especially  with 
Commanding  Officers  who  may  be  occupied  with  other  tasks.  After  all  requisite  approvals 
are  obtained,  the  SK  assigns  it  a  requisition  number.  At  this  point,  SNAP  maintenance 
and  financial  modules  will  be  automatically  updated.  The  procurement  document  and  any 
ancillary  documents,  such  as  Material  Safety  Data  Sheet  (MSDS),  is  then  ready  for 
transmission,  or  batched  and  awaiting  transmission,  via  EDI  to  the  procuring  activity, 
usually  the  local  FISC.  RPT  is  identical  for  credit  card  purchases.  [Approvals  took 
anywhere  from  30  minutes  to  a  day,  depending  on  the  nature  of  the  requirement  (e.g. 
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HA7MAT)  and  the  availability  of  the  Department  Head,  Commanding  Officer,  etc.  It 
took  two  to  four  minutes  to  assign  a  requisition  number.] 


Task 

Duration 

Duration 

(repair  parts) 

(MVO) 

Initial  research 

2  min  -  1  hr 

2  min  -  1  hr 

Order  via  ANSRS 

20  -  45  min 

2-5  min 

Prepare  procurement  document 

5-10  min 

5-10  min 

SK  administrative  screening 

1-2  min 

1  -  2  min 

SK  technical  screening 

10  min  - 1  hr 

10  min  - 1  hr 

Approvals 

30  min  to  24  hrs 

30  min  -  24  hrs 

Assign  requisition  number 

2-4  min 

2-4  min 

Total  RPT 

1.17  hrs  -  27.02  hrs 

52  min  -  26.35  hrs 

Table  3.6  ANSRS  RPT  for  Ships 


b.  ANSRS  Requisition  Submission  Time  (RST)  and  ANSRS 

Procurement  Administrative  Lead  Time  (PALT) 

ANSRS  RST  and  ANSRS  PALT  for  procurement  documents  that  are 
transmitted  to  the  procurement  activity/FISC  for  award  are  diagrammed  in  Figure  3.5. 
RST  and  PALT  for  credit  card  buys  is  too  simple  a  flow  to  diagram,  as  will  become 
evident  in  the  preceding  paragraphs. 

RST  is  the  interval  between  the  moment  RPT  is  completed  to  the  moment 
the  procurement  document  is  accepted  by  the  procurement  activity.  Delays  caused  by 
requests  for  additional  data  are  included  in  RST.  With  ANSRS,  however,  those  requests 
can  be  made  via  EDI;  so  too  can  the  responses  from  the  ship.  RST  is  nonexistent  in  credit 
card  purchases  because  these  requirements  are  never  transmitted  to  the  FISC.  After  the 
requisition  number  is  assigned,  the  document  is  automatically  accepted  by  the  buyer  (i.e.. 
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credit  card  holder,  likely  the  same  SK).  [Ships  reported  transmitting  six  to  eight 
nonstandard  procurements  to  the  procuring  activity/FISC  a  month.]  The  procurement 
document  is  transmitted  to/received  at  the  FISC  via  EDI  where  it  is  administratively 
screened  by  Customer  Service.  Next,  FISC  Technical  conducts  another  technical 
screening  for  NSN  substitutes,  HAZMAT  compliance,  and  other  restrictions  to  shipboard 
use.  Any  discrepancies  are  resolved  with  the  ship  via  EDI  (there  should  be  no  data 
omissions).  After  technical  screening,  the  document  is  ready  for  the  FISC  buyer  to 
contract  award.  [Since  all  FISCs  reported  difficulties  with  receiving  transmissions  from 
a  ship  and/or  internal  incompatibility  problems,  RST  completion  is  estimated  at  45 
minutes  to  1.5  hours.  RST  for  credit  card  buys  was  nonexistent.] 

PALT  is  the  interval  between  the  moment  the  procurement  document  is 
accepted  by  the  buyer  to  the  moment  the  contract  is  awarded  (or,  the  amount  of  time  it 
takes  the  buyer  to  make  the  buy).  PALT  standards  vary  among  different  procurement 
activities.  PALT  for  credit  card  purchases  is  assigned  to  the  SK  who  contracts  with  a 
local  vendor  for  the  repair  part  or  consumable  material  requirement.  [Depending  on  the 
urgency,  PALT  at  the  FISC  took  30  minutes  to  15  days.  PALT for  credit  card  buys  made 
by  the  ship  took  30  minutes  to  one  hour.] 
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Process  Segment 

Duration 

FISC 

RST 

45  min  - 1.5  hrs 

PALT 

30  min  -  1  hr 

Total  RST/PALT  at  FISC 

1.25  -  2.5  hrs 

Credit  card  (onboard  a  ship) 

RST 

N/A 

PALT 

30  min  - 1  hr 

Total  RST/PALT  on  ship 

30  min  - 1  hr 

Table  3.7  ANSRS  RST  and  PALT  (Ship  to  FISC) 


|  Process  Segment 

Duration 

RPT 

52  min  -  27.02  hrs 

RST 

0  - 1.5  hrs 

PALT 

30  min  - 1  hr 

Total  Cycle  Time 

1.37  -  29.52  hrs 

Table  3.8  ANSRS  Cycle  Time  (Ship  to  FISC) 


D.  CHAPTER  SUMMARY 

This  chapter  began  with  brief  discussions  on  ANSRS  implementation  background, 
schedule,  and  responsibilities.  Next,  the  prototype  Afloat  Customer  Module  was 
presented.  The  core  of  this  chapter  discussed,  diagrammed,  and  quantified  the  manual 
procurement  process  on  both  surface  ships  and  submarines  and  the  ANSRS  procurement 
processes  on  ships  (ANSRS  has  not  been  installed  onboard  any  submarine  to  date).  Task 
completion  times  were  given  as  a  minimum  to  maximum  value  range. 
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Manual  RPT  for  both  surface  ships  and  submarines  are  comparable.  However, 
repair  parts  take  approximately  37  percent  longer  to  order  than  MVO  requirements, 
principally  because  of  time  expended  opening  a  maintenance  job,  and  submarines  rarely 
order  a  nonstandard  repair  part.  ANSRS  creates  some  small  time  savings  for  ships  but 
does  not  significantly  reduce  the  range;  similar  results  are  likely  for  submarines. 

RST  and  PALT  differences  between  ships  and  submarines  can  be  attributed  to 
whether  or  not  the  requirement  has  to  be  delivered  to  an  external  procurement  activity 
and,  if  so,  the  delivery  method  used.  For  ship  requirements  hand-delivered  to  the  FISC, 
RST/PALT  ranged  from  1.75  hrs  to  15  days;  mailed  documents  took  from  three  to  25 
days.  Submarines  hand-deliver  all  their  procurement  documents  to  an  intermediate 
support  activity  such  as  SLSC-PH.  For  submarines,  RST/PALT  for  FISC  buys  ranged 
from  1 .75  hrs  to  10  days.  The  shorter  maximum  is  attributed  to  the  expediting  efforts  of 
the  SLSC-PH,  which  is  located  in  the  FISC  building.  ANSRS  creates  significant 
RST/PALT  time  savings  for  ships  when  near-instantaneous  delivery  time  and  elimination 
of  additional  technical  screening  at  the  FISC  is  factored  in.  Maximum  values  are  reduced 
from  25  days  to  as  little  as  2.5  hours.  When  credit  cards  are  used,  RST/PALT  maximums 
for  ships  are  about  half  of  that  for  submarines,  1.5  hours  compared  to  3  hours.  Submarines 
(in  SUBPAC)  do  not  have  their  own  credit  cards  as  yet  and  must  hand-deliver  the 
requirement  to  the  intermediate  support  activity.  ANSRS  reduces  RST/PALT  for  credit 
card  time  by  30  minutes  on  both  sides  of  the  range,  principally  because  of  paperwork 
reductions.  ANSRS  creates  reductions  in  Cycle  Time  maximums  for  ships  from  26  days 
under  the  manual  process  to  under  30  hours.  ANSRS  would  likely  produce  a  similar 
maximum  for  submarines. 
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Figure  3.3 

Manual  Procurement  Process  Flow:  Requisition  Submission  Time  (RST)  and 
Procurement  Administrative  Lead  Time  (PALT)  for  Submarines 
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Figure  3.4 


ANSRS  Procurement  Process  Flow:  Requisition  Preparation  Time  (RPT)  for 

Surface  Ships 
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Time  (PALT)  for  Surface  Ships 
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IV.  DATA  COLLECTION  AND  ANALYSES 


This  chapter  focuses  on  the  questionnaire  used  in  this  study  (Appendix  E).  It  was 
selected  as  the  primary  research  tool  to  measure  the  effectiveness  of  ANSRS  prototype 
implementation.  Background  is  presented,  responses  are  discussed  and  tabulated  (where 
applicable),  and  the  results  are  analyzed.  Additionally,  an  example  of  an  unsuccessful 
prototype  installation  is  discussed,  diagrammed,  and  analyzed.  Finally,  a  brief  analysis  on 
measures  of  effectiveness  and  cost  is  presented. 

A.  QUESTIONNAIRE  BACKGROUND 

In  order  to  ascertain  the  efficacy  of  ANSRS  to  the  Navy  customer,  a  questionnaire 
was  developed  and  submitted  to  all  Pacific  Fleet  commands  installed  with  any  one  of  the 
three  ANSRS  prototype  modules.  On  5  November,  1997,  the  questionnaire  was  directly 
emailed  to  27  points  of  contact  assigned  to  21  commands.  These  commands  consisted  of 
eight  SURFPAC  ships,  one  AIRPAC  ship,  seven  FISC/FISC  satellites,  one  Naval  Air 
Station,  two  Ship  Repair  Facilities  (SRF)  and  two  Fleet  Activities  (FLEACT)  in 
California,  Washington  (State),  Hawaii,  and  Japan.  Follow-up  telephone  calls  revealed 
some  instances  where  software  incompatibility  rendered  the  questionnaire  unreadable, 
requiring  13  questionnaires  to  be  resent  via  fax  and  three  to  be  subsequently  conducted 
over  the  telephone  (by  request  of  the  respondent).  Because  some  ships  were  underway 
and  could  not  be  reached  by  telephone  until  late  in  the  month,  the  last  fax  was  transmitted 
on  20  November.  All  but  three  points  of  contact  were  confirmed  to  have  received  the 
questionnaire  (no  telephone  number  was  provided  for  these  three,  and  email  follow-ups 
were  not  answered).  The  accompanying  cover  letter  requested  that  all  ANSRS  users 
within  a  command  be  given  the  opportunity  to  respond.  Discussions  with  a  cross-section 
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of  the  commands  suggested  that  approximately  107  personnel  were  potential  respondents. 
Eventually,  42  responses  were  received  (39%),  consisting  of  8  Supply  Corps  Officers,  18 
Storekeepers,  4  RPPOs,  and  12  civilians.  Follow-up  questions  were  conducted  with  16 
points  of  contact. 

B.  QUESTIONNAIRE  RESPONSES  AND  ANALYSES 

This  section  is  divided  into  the  broad  categories  of  the  questionnaire.  Some 
questions  required  either  short  or  essay  responses,  while  others  were  yes/no  or  Likert- 
Type  Scale  in  design.  First,  the  rationale  behind  each  category  is  discussed.  Next,  all 
questionnaire  questions  are  repeated  verbatim  (in  bold  type),  responses  tabulated  where 
applicable,  and  remarks  provided  for  clarification.  An  analyses  is  presented  at  the  end  of 
each  category. 

1.  Manual  Open  Purchase  Process  (Pre-ANSRS,  Pre-Credit  Card) 

This  category  of  questions  was  designed  to  obtain  information  on  the  manual 
nonstandard  procurement  processes  flow  from  the  end-users  perspective,  problems  and 
bottlenecks  encountered,  and  LRT.  This  information  was  incorporated  into  those  sections 
in  Chapters  II  and  III  that  discuss  and/or  quantify  the  manual  procurement  process.  It  was 
also  used,  in  part,  to  diagram  Figure  3.1. 

a.  Briefly  describe  the  process  flow  (from  end-user  to  the 

contracting  activity’s  customer  service  desk),  approximate  time 
involved  in  each  step,  the  personnel  involved  in  each  step,  and 
any  paperwork  or  document  requirements. 

Remarks:  See  Figure  3 . 1  for  a  composite  manual  nonstandard 
procurement  process  flow. 
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b.  What  problems  did  (do)  you  encounter  with  the  manual  open 
purchase  process?  What  and  where  in  the  process  were  (are) 
the  bottlenecks? 

Responses:  Obtaining  signatures:  13(31%) 

Lack  of  communication  between 
ship  and  FISC  13(31%) 

Incomplete  information  from 
end-user:  12  (29%) 

Remarks:  Some  respondents  provided  more  than  one  answer. 

c.  Approximately  how  long  did  (does)  it  take  to  receive  your 
material  this  way? 

Responses:  Range:  3  weeks  to  1  month  for  CONUS 

activities 

30  to  60  days  for  OCONUS  activities 

Remarks:  This  question  would  have  been  more  germane  to  this 
study  had  it  asked  “Approximately  how  long  does  it  take  for  your 
requirement  to  be  awarded  at  the  procurement  activity?” 

Analysis:  Afloat  and  shore  end-users  had  little  difficulty  explaining  the  process 
flow  and  the  bottlenecks  encountered.  They  could  not,  however,  accurately  quantify  the 
temporal  aspects  of  the  process.  This  was  not  unexpected;  despite  the  evident  need  to 
automate  processes  in  this  time  of  downsizing,  measuring  those  processes  is  a  difficult 
task,  at  best.  This  deficiency  has  lead  to  more  than  one  automated  system  to  be  developed 
and  implemented  at  great  expense  within  the  fleet,  only  to  be  abandoned  or  underutilized 
by  those  it  was  meant  to  help  because  it  could  not  be  shown,  quantitatively,  how  it  would 
improve  the  process.  Of  the  three  bottlenecks  mentioned,  only  the  former,  obtaining 
signatures,  will  likely  be  exacerbated  by  automation  because  a  busy  officer  is  more  likely 
to  sign  a  piece  of  paper  presented  during  a  small  break  in  the  action  than  drop  everything 
to  log  on  the  terminal.  Expediency  will,  in  all  probability,  lead  to  password  violations. 
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2. 


IMP  AC  Credit  Card 


ANSRS  is  the  only  known  program  (to  the  author)  that  captures  credit  card 
demand  and  is  expected  to  be  deployed  throughout  the  fleet.  This  category  was  designed 
to  provide  an  idea  on  how  prevalent  credit  card  use  is  in  the  fleet. 

a.  Do  you  currently  use  the  IMPAC  credit  card? 

Responses:  Yes:  29  (69%) 

No:  13  (31%) 

b  If  so,  since  when? 

Responses:  Range:  2-11  months. 

c.  Describe  the  workload  that  was  reduced  or  eliminated.  By 
what  percentage? 

Responses:  Simplifies  procurement  process:  15 

(52%  of  credit  card  users) 

Easier  tracking/monitoring:  7 

(24%  of  credit  card  users) 

Receive  material  faster:  21 

(72%  of  credit  card  users) 

Range:  90  -  100% 

Remarks:  Some  respondents  provided  more  than  one  answer. 
RPPOs  reported  100%  workload  reductions. 

d.  Describe  the  workload  that  was  increased  or  created.  By  what 
percentage? 

Responses:  More  open  purchase  demands: 

(41%  of  credit  card  users) 

Increased  validation  of  requirements 
(41%  of  credit  card  users) 

Bill/payment  auditing: 

(66%  of  credit  card  users) 

Range: 


12 
:  12 
19 

30  -75% 
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e.  Do  you  feel  that  the  credit  card  makes  your  job  easier? 

Harder?  Why? 

Responses:  Easier:  24 

(83%  of  credit  card  users) 

Harder:  5 

(17%  of  credit  card  users) 

Remarks:  Responses  to  the  third  part  of  this  question  are 
incorporated  into  questions  c  and  d  All  shipboard  personnel 
responded  easier. 

Analysis:  All  but  one  ship  used  the  credit  card,  which  attests  to  its  popularity  with 
afloat  commands.  However,  several  respondents  reported  an  increased  reliance  on  the 
credit  card  for  ordering  repair  parts  and  a  corresponding  increase  in  total  open  purchase 
requests.  It  appears  that  many  maintenance  personnel  are  focusing  their  efforts  on 
identifying  local  sources  of  procurement  instead  of  relying  on  the  supply  system.  This 
could  result  in  negative  configuration  control  ramifications  as  non-approved  parts  make 
their  way  into  the  “this  is  what  we’ve  always  used”  category  while  the  equipment  keeps 
failing.  It  could  also  degrade  readiness  for  deployed  ships  when  the  equipment  breaks  and 
there  is  no  local  supplier.  Total  Asset  Visibility  (TAV)  objectives  are  also  compromised. 
However,  it  also  points  out  that  the  “system”  is  not  satisfying  all  of  its  customers. 

3.  ANSRS  Training 

This  categoiy  was  designed  to  obtain  customers’  perceptions  on  the  quality  of  the 
training  provided.  Its  intent  was  to  determine  whether  training  was  successful  in  providing 
the  necessary  skills  to  operate  ANSRS  and  alleviating  any  initial  trepidation  towards  its 
use. 
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a.  When  did  you  first  hear  about  ANSRS? 

Responses:  Prior  to  install:  35  (83%) 

During  install:  7(17%) 

Remarks:  One  command  reported  a  37  month  notification;  most 
reported  8-9  months 


b.  What  types  of  training  did  you  receive?  Duration? 


Responses:  None: 

Self-training: 

1  on  1: 

Group: 

Lecture: 

Hands-on: 

Other: 


0 

0 

20  (48%) 

1  hr. 

16  (38%) 

1  to  4  hrs 

14  (33%) 

1  to  4  hrs 

11  (26%) 

2  to  4  hrs. 

0 


Remarks:  Some  respondents  reported  receiving  more  than  one  type 
of  training. 

c  Would  you  describe  the  training  as  good,  thorough,  and 
worthwhile?  If  not,  what  would  have  helped? 

Responses:  Yes:  25  (60%) 

No:  17  (40%) 

Remarks:  Yes  includes  “adequate”  or  “satisfactory”  responses. 
Some  respondents  felt  that  training  should  include  actual 
transmissions  and/or  responses  from  the  FISCs.  Two  (from 
different  commands)  felt  that  the  instructors  did  not  know  their 
subject  matter  very  well.  One  reported  that  people  walked  out 
during  the  training  session. 

d.  At  what  point  did  you  understand  what  ANSRS  was  intended 
to  do? 


Responses:  Pre-training:  14  (33%) 

During  training:  16(38%) 

After  working  with  it:  2  (5%) 

Still  somewhat  unclear:  10  (24%) 
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e.  At  what  point  did  you  understand  how  to  use  ANSRS? 

Responses:  During  training:  19  (45%) 

After  working  with  it:  1 3  (3 1  %) 

Still  somewhat  unclear:  10  (24%) 

/  How  difficult  is  it  for  you  to  adequately  train  someone  within 
your  organization  on  ANSRS? 


Responses:  Haven’t  had  to  yet:  16(38%) 

Not  difificult/easy:  15  (36%) 

Moderately  difficult:  1 1  (26%) 

Very  difficult/hard:  0 

Impossible:  0 


g.  How  would  you  improve  ANSRS  training  within  your 
command? 

Responses:  Hands-on  training:  15 

(58%  of  those  who  have  trained) 

Devote  more  time:  3 

(12%  of  those  who  have  trained) 

No  response:  8 

(3 1%  of  those  who  have  trained) 

h.  Do  you  know  where  to  get  assistance  within  your  organization 
if  needed? 

Responses:  Yes:  37  (88%) 

No:  5  (12%) 

i  Do  you  know  where  to  get  assistance  outside  your  organization 
if  needed? 

Responses:  Yes:  36  (86%) 

No:  6  (14%) 

j.  Do  you  know  how  or  where  to  send  feedback  or  suggestions? 

Responses:  Yes:  31  (74%) 

No:  11(26%) 

Analysis:  All  respondents  reported  receiving  at  least  one  type  of  training. 
However,  40  percent  did  not  find  the  training  worthwhile,  and  ten  percent  are  still  unclear 
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on  how  to  use  ANSRS.  Additionally,  14  percent  of  the  respondents  did  not  know  where 
or  from  whom  to  get  outside  assistance,  and  26  percent  did  not  know  how  or  where  to 
send  feedback  and  suggestions.  Additionally,  42  percent  of  personnel  who  attempted  to 
train  someone  within  their  command  found  the  task  moderately  difficult.  These  indicators 
point  to  the  essentiality  of  tailoring  training  to  the  customers’  needs. 

4.  ANSRS  Usage 

This  category  was  primarily  designed  to  provide  the  information  to  be  used  in 
comparison  with  the  manual  procurement  process;  this  information  was  incorporated  into 
Chapter  III  and  was  used,  in  part,  to  diagram  Figures  3.4  and  3.5.  It  was  also  intended  to 
discover  if  a  causal  relationship  could  be  determined  between  usage,  training,  and 
installation. 


a.  How  often  do  you  use  ANSRS? 


Responses:  Daily:  20  (48%) 

Weekly:  1 1  (26%) 

A  few  times  per  month:  0 

Rarely:  0 

Never:  11(26%) 

b.  What  do  you  use  ANSRS  for? 

Responses:  NSN  screening:  15 

(48%  of  ANSRS  users) 

HAZMAT  screening:  4 

(13%  of  ANSRS  users) 

Mandatory  source  screening:  15 

(48%  of  ANSRS  users) 

Credit  card  procurements:  12 

(39%  of  ANSRS  users) 

Other  small  purchases:  1 1 

(35%  of  ANSRS  users) 

Large  procurements:  17 

(55%  of  ANSRS  users) 

Other:  0 
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c. 


Remarks:  Some  respondents  reported  more  than  one  use. 

Who  uses  ANSRS  in  your  organization? 


Responses: 


Commanding  Officer: 

0 

Executive  Officer: 

0 

Supply  Officer: 

12 

HAZMAT  Officer: 

0 

Storekeepers: 

29 

RPPOs: 

44 

Others. 

19 

d.  Briefly  describe  the  process  flow  (from  end-user  to  the 
contracting  activity’s  customer  service  desk),  approximate  time 
involved  in  each  step,  the  personnel  involved  in  each  step,  and 
any  paperwork  or  document  requirements. 

Remarks:  See  Figures  3.4  and  3.5  for  composite  ANSRS 
procurement  process  flows. 

e.  What  and  where  in  the  process  are  the  bottlenecks? 

Responses:  No  internal  interface/cannot 

update  files:  29  (69%) 

Obtaining  signatures:  13  (31%) 

No  external  interface/connection:  2  (5%) 

Remarks:  Some  respondents  provided  more  than  one  answer. 

f.  Approximately  how  long  does  it  take  to  receive  your  material 
this  way? 

Responses:  No  significant  variation  from  question  1  b  responses 
(P-  53). 

Remarks:  Same  as  question  lb  remarks  (p.  53). 

g.  Does  ANSRS  decrease  your  workload  (e.g.  saves  time,  saves 
paperwork?) 

Responses:  Yes:  21  (68%  of  ANSRS  users) 

No:  10  (32%  of  ANSRS  users) 
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h.  If  yes,  describe  how  and  rank  in  order  of  importance  to  you. 


Responses:  Trips  to/time  spent  at  the  FISC:  13 

(62%  of  yes  respondents) 

No  response:  8 

(38%  of  yes  respondents) 

i.  Does  ANSRS  increase  your  workload  in  any  area? 

Responses:  Yes:  27  (87%  of  ANSRS  users) 

No:  4  (13%  of  ANSRS  users) 

j.  If  yes,  describe  how. 

Responses:  Double  entry  of  data:  22 

(81%  of yes  respondents) 

Added  step  in  credit  card  process:  8 

(30%  of  yes  respondents) 

No  response:  9 

(33%  ofyes  respondents) 

Remarks:  Some  respondents  provided  more  than  one  answer. 

k.  What  should  ANSRS  do  for  you  that  it  cannot  now  do? 


Responses:  Interface  with  FEDLOG:  1 3  (3 1  %) 

ANSRS  should  match  manual  forms:  8  (19%) 
Import  scanned  files:  4  (10%) 

Make  job  easier:  4(10%) 

Upload  to  APADE:  2  (5%) 

No  response:  1 1  (26%) 


L  Does  your  command  receive  a  Non-Standard  Data  Base 
(NSDB)  update  on  a  regular  basis? 

Responses:  Yes:  24  (57%) 

No:  18(43%) 

Remarks:  No  includes  “don’t  know”  responses. 
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nu  If  yes,  how  often? 

Responses:  Once:  8 

(33%  of yes  respondents) 

No  response:  16 

(67%  ofyes  respondents) 

n.  Does  ANSRS  interface  with  FEDLOG? 

Responses:  Yes:  22  (52%) 

No:  20  (48%) 

o.  Is  ANSRS  installed  on  a  LAN  within  your  organization? 

Responses:  Yes:  21  (50%) 

No:  21  (50%) 

p.  Do  you  like  ANSRS? 

Responses:  Yes:  23  (55%) 

No:  7  (17%) 

Remarks:  12  (30%)  did  not  understand  this  question.  It  should  be 

rewritten  to  ask  “Do  you  like  the  concept  behind  ANSRS?” 

Analysis:  The  ANSRS  prototype  has  not  been  very  successful.  More  than  a 
quarter  of  respondents  don’t  even  use  it  and  another  ten  percent  are  using  it  less 
frequently  than  before.  Those  that  do  use  ANSRS  are  not  receiving  the  full  benefits  that 
ANSRS  was  designed  to  provide.  Less  than  half  of  those  who  still  use  ANSRS  do  not  use 
it  for  technical  screening.  Although  68  percent  of  those  using  ANSRS  reported  that  it 
lessened  their  workload,  the  major  reason  cited  was  that  it  saved  a  trip  to  the  FISC. 
Conversely,  87  percent  of  those  who  use  ANSRS  reported  that  it  increased  their 
workload.  By  far,  the  most  common  problem  encountered  was  double  entry  of  data 
caused  by  the  lack  of  interface  with  other  systems,  principally  SNAP.  It  appears  that, 
although  training  was  not  fully  successful,  indoctrination  was;  the  majority  of  respondents 
were  eager  to  have  a  system  like  ANSRS,  but  “one  that  works.” 
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5. 


Miscellaneous 


This  category  was  designed  to  complement  the  previous  questions  and  to  provide 
specific  information  on  all  nonstandard  procurements  initiated  by  each  command  and  the 
amount  of  additional  equipage  required  to  implement  and  use  ANSRS.  This  information 
was  also  incorporated  into  Chapter  III. 

a.  On  average,  how  many  open  purchase  requisitions  do  you 
submit  per  month  for  credit  card  purchases? 


Responses:  Less  than  6:  0 

6-10:  0 

11-15:  0 

16-20:  4 

(14%  of  credit  card  users) 

21-25:  12 

(41%  of  credit  card  users) 

More  than  25:  13 


(45%  of  credit  card  users.  Range:  33  to  63) 

b.  Non-credit  card  small  purchases? 


Responses:  Less  than  3:  31(74%) 

3-5:  3(7%) 

6-10:  5  (12%) 

11-15:  0 

16-20:  3  (7%) 

More  than  20:  0 

a  Large  purchases? 

Responses:  1:  0 

2:  2  (5%) 

3:  1  (2%) 

4:  1  (2%) 

More  than  4:  6(1 4%) 


(Range:  6  to  8) 

Remarks:  30  (71%)  respondents  reported  zero. 
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d.  Approximately  what  percentage  of _ open  purchases  are  for 

repair  parts  (vice  consumables,  equipage,  services,  etc.)? 

Responses:  Credit  card:  1 8  (62%) 

(of  credit  card  users.  Range:  25%  to  95%) 
Non-credit  card  small:  1 1  (26%) 

(Range:  20%  to  25%) 

Large:  7  (17%) 

(Range:  5%  to  25%) 

e.  Approximately  what  percentage  of _ open  purchases  are 

procured  using  ANSRS? 

Responses:  Credit  card:  14  (48%) 

(of  credit  card  users.  Range:  25%  to  90%) 
Non-credit  card  small:  8  (19%) 

(Range:  25%  to  100%) 

Large:  17(40%) 

(Range:  10%  to  100%) 

f  What  kinds  and  how  much  extra  equipage  (e.g.  terminals)  was 
needed  to  implement  ANSRS  within  your  organization? 

Responses:  One  terminal  and  monitor:  4  (10%) 

None  or  no  response:  38  (90%) 

Analysis:  One  afloat  command  reported  that  95  percent  of  its  credit  card 

purchases  were  for  repair  parts.  This  appears  grossly  excessive,  but  the  ship  could  not  be 

reached  for  clarification.  Generally,  the  usage  rates  reported  were  credible  and  ordinary. 

6.  Additional  Comments 

This  section  was  used  to  elicit  any  comments  that  respondents  felt  were  important 
but  not  addressed  above.  However,  most  comments  applied  to  the  previous  categories 
and  were  incorporated  therein. 

Comments: 

Using  ANSRS  less  frequently  than  before 
ANSRS  should  only  be  used  at  FISC: 

ANSRS  still  being  installed: 

No  response  to  feedback: 


4  (10%) 
3  (7%) 

2  (5%) 

1  (2%) 
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C.  ANSRS  IMPLEMENTATION  AT  FISC  PEARL  HARBOR 

When  ANSRS  is  unsuccessfully  implemented,  human  energy  is  expended  to  “work 
around”  the  problems  encountered,  resulting  in  other  process  flow  disruptions  and  causing 
resistance  to  change.  Figure  4. 1  illustrated  how  the  unsuccessful  implementation  of 
ANSRS  at  FISC-PH  creates  and  inefficient  process  flow,  and  in  one  instance  actually 
causes  additional  workload  for  the  ship. 

Procurement  document  data  in  ANSRS  format  is  either  hand-delivered  on  a  disk 
or  transmitted  via  SALTS  to  Customer  Service.  If  received  via  SALTS,  the  data  is 
downloaded  to  a  disk  because  SALTS  does  not  interface  with  ANSRS.  The  disk  is 
walked  to  Technical  for  technical  screening.  The  procurement  data  can  be  sent  via  email, 
but  this  mode  of  transmission  bypasses  Customer  Service  and  instead  goes  directly  to  a 
terminal  in  Technical.  The  data  is  imported  into  ANSRS  for  technical  screening.  If  there 
are  no  discrepancies,  a  hard  copy  of  the  DD  1155  is  printed  and  walked  to  the  buyer. 
However,  if  either  Technical  or  the  buyer  discover  any  discrepancies,  the  ship  is  contacted 
and  a  brand  new  procurement  document,  not  the  old  one  with  updated/corrected 
information,  must  be  generated  by  the  ship  and  transmitted.  Corrections  cannot  be  made 
by  FISC  personnel. 

D.  MEASUREMENTS  OF  EFFECTIVENESS  AND  COST 

One  may  conclude  that,  generally,  automating  any  manual  process  will  produce 
efficiencies  in  labor,  paper,  time,  and  other  resources.  However,  unless  one  can  measure 
segments  of  the  process  and  apply  costs,  one  cannot  quantify  those  efficiencies  with  any 
degree  of  precision.  Since  the  objective  of  this  study  is  to  determine  the  feasibility  of 
implementing  ANSRS  within  SUBPAC,  the  ability  to  quantify  data  and  conclusions  is 
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imperative.  Research  indicates,  however,  that  few  measures  of  effectiveness  and  costs 
related  to  the  nonstandard  process  exist;  those  that  do  are  not  standardized. 

The  analysis  presented  at  the  end  of  paragraph  B1  stated  that  those  personnel  who 
responded  to  the  questionnaire  had  a  difficult  time  providing  temporal  measures.  This 
task  was  equally  difficult  for  NAVICP,  NAVSUP,  contracting,  and  contractor  personnel. 
The  measures  are  just  not  there.  To  compensate,  the  author  improvised:  “Cycle  Time” 
defined  as  a  truncated  segment  of  its  usual  meaning — LRT — but  with  an  additional 
segment  to  measure  the  time  it  takes  to  develop  and  process  a  requirement  before 
assigning  a  requisition  number  to  it — RPT.  The  author  attended  a  symposium  on  LRT  in 
August  1997  and  discovered  that  although  RST  was  defined,  there  were  many  disparate 
opinions  on  how  to  measure  it,  and  no  rational  way  to  cost  it.  PALT  is  a  generally 
understood  term,  but  it  too  does  not  conform  to  any  hard  and  fast  standard,  and  any  cost 
measurements  associated  with  it  could  not  be  provided  to  the  author. 

E.  CHAPTER  SUMMARY 

ANSRS  prototype  implementation  has  not  wrought  the  efficiencies  that  were 
intended.  Several  questionnaire  responses  and  the  unsuccessful  implementation  of 
ANSRS  at  FISC  Pearl  Harbor  support  this  argument.  Training  was  only  partially 
effective.  Connectivity  problems,  both  internal  and  external,  are  significant  impediments 
to  ANSRS  acceptance  and  usage.  However,  the  efficiencies  and  resultant  workload 
reductions  that  ANSRS  could  provide  are  attractive  to  and  desired  by  fleet  customers. 

The  paucity  of  standardized  and/or  useful  measures  of  effectiveness  and  cost  creates  a 
significant  obstacle  to  current  ANSRS  implementation  objectives  and  future  ANSRS 
improvement  initiatives.  Preliminary  benchmarks  are  offered  with  the  survey  results.  For 
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maximum  ranges,  problems  should  be  identified  and  resolved  so  to  reduce  variation  in  the 
process. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


The  data  collected  for  this  study,  while  not  always  as  precise  as  desired,  is 
nonetheless  sufficient  to  draw  conclusions  pertinent  to  the  objective  of  this  study  and 
identify  areas  that  warrant  further  research.  This  final  chapter  begins  with  conclusions  and 
recommendations  and  ends  with  peripheral  issues  that  appear  to  be  valid  candidates  for 
later  research. 

A.  CONCLUSIONS  AND  RECOMMENDATIONS 

1.  It  would  be  beneficial  to  implement  ANSRS  within  SUBPAC. 

ANSRS  should  be  implemented  within  SUBPAC,  on  submarines  and  at  SLSC-PH 
(to  include  the  other  SUBPAC  shore/tender  activities  that  provide  the  same  types  of 
services  as  SLSC-PH).  The  data  indicates  that  ANSRS  implementation  can  create 
significant  time  efficiencies  for  ships.  A  comparison  of  Tables  3.3  and  3.8  shows  that  total 
Cycle  Time  can  be  reduced  from  a  high  maximum  of  26  days  to  a  low  maximum  of  just 
over  one  day.  This  significant  reduction  is  predicated  on  the  elimination  of  connectivity 
glitches,  a  broadly  stocked  NSDB,  and  a  minimum  of  document  errors  generated  by  the 
ship.  Indeed,  if  left  unresolved  these  problems  will  create  the  same  or  worse  results  as  the 
prototype  has  produced  so  far.  The  development  of  the  Windows  NT  version  is  a  step  in 
the  right  direction. 

The  entire  case  for  implementing  ANSRS  within  SUBPAC  is  not  based  solely  on 
efficiencies  from  which  ships  might  benefit.  As  stated  in  the  opening  paragraph  of  Chapter 
III,  the  submarine  community  is  logistically  different  than  the  surface  and  air  communities. 
SUBPAC’ s  successful  efforts  to  reduce  the  workload  of  the  afloat  Supply  Department 
(the  stated  rationale  behind  SLSC-PH,  et  al .)  allows  submarine  supply  personnel  to 
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concentrate  on  configuration  management  and  achieve  a  greater  than  93  percent 
configuration  accuracy  rate.  SLSC-PH  also  provides  a  dedicated  cadre  of  personnel  to 
expedite  all  submarine  requirements  and  act  as  experts  at  “working  the  system”.  Because 
of  these  advantages,  submarines  can  better  rely  on  the  supply  system  and  rarely  order  a 
nonstandard  repair  part.  These  advantages  may  erode,  however,  as  the  push  towards 
inventory  reductions  and  reliance  on  COTS  and  NDI — CANDI — equipment,  which  will 
not  likely  be  supported  by  the  supply  system,  gains  momentum.  The  secondary  support 
then,  for  implementing  ANSRS  on  submarines  comes  from  the  ability  of  ANSRS  to 
provide  NAVICP  with  equipment  support  histories  and  demand  data,  to  be  used  by 
NAVICP  to  conduct  deep  technical  screening,  maintain  the  integrity  of  submarine  Weapon 
Systems  Files,  and  avert  repair  part  shortages.  There  is  no  evidence  to  suggest  that 
ANSRS  implementation  will  cause  significant  operational/relational  changes  between 
submarines,  shore  support  activities  such  as  SLSC-PH,  and  FISCs. 

a.  Build  a  record  of  success  before  implementing  ANSRS  within 
SUBPAC. 

A  proven  record  of  success  should  be  achieved  within  the  other  Navy 
communities  before  implementation  begins  within  SUBPAC.  Based  on  informal 
interviews  with  numerous  submarine  officers  and  enlisted,  the  interconnectivity  problems 
between  SNAP  and  ANSRS,  and  those  between  customer,  procurement  activity,  and 
NAVICP  must  be  resolved,  or  any  briefing  with  “ANSRS”  and  “improved  readiness”  will 
likely  fall  on  deaf  ears,  and  may  instead  be  seen  as  a  threat  to  workload  reduction 
imperatives. 
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b.  Develop  tailored  training  for  submarines  and  fund  pierside 
experts. 

Conduct  personal  interviews  with  personnel  at  all  levels  of  SUBPAC  to 
determine  readiness  objectives  and  methods  use  to  attain  them.  Paper  surveys  and 
questionnaires  are  not  as  effective  as  personal  interviews.  Operational  necessities  will  not 
always  conform  to  preset  training  schedules;  a  pierside  expert  or  two  at  the  FISC  will  be 
able  to  provide  hands-on  training  to  submarines  (and  other  commands)  during  windows  of 
opportunity.  They  can  hold  group  training  at  the  FISC  if  there  is  surge  in  demand.  They 
will  also  be  available  to  answer  questions,  take  action  on  feedback,  and  obtain  NSDB 
updates  for  commands  that  may  have  missed  getting  one  because  of  deployment.  In  short, 
they  will  help  sustain  user  proficiency  (afloat  and  ashore),  positively  impact  logistics 
readiness,  and  cut  down  on  training  travel  costs. 

c.  Devise  a  method  for  obtaining  signatures  off  line. 

The  bottleneck  common  to  both  the  manual  and  ANSRS  procurement 
process  questionnaire  questions  was  the  difficulty  of  obtaining  approval  signatures.  The 
author  can  personally  attest  that  SNAP  access  passwords  belonging  to  Department  Heads 
are  given  to  subordinates.  The  author  can  also  personally  attest  that  when  the  practice 
was  stopped,  the  backlog  of  non-approved  requirements  in  SNAP  rose  dramatically  and 
rapidly.  The  reason  for  this  is  because  it  is  often  impractical  for  officers  on  watch, 
conducting  engineering  drills,  etc.  to  break  away  and  access  a  terminal.  FEDEX  has  the 
ability  to  obtain  paperless  signatures  they  can  then  upload  into  their  computer  system. 
NAVMASSO  should  easily  be  able  to  adapt  this  technology  to  ANSRS.  A  hard  copy  of 
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the  requirement  will  have  to  be  printed  out  for  review  by  the  signatory,  but  that  is 
preferable  to  doing  nothing. 

2.  To  measure  and  improve  the  process,  ANSRS  performance  and  costs 
should  be  measurable. 

ANSRS  performance  and  costs  have  to  be  measurable.  It  is  not  sufficient  to  only 
install  a  system  such  as  ANSRS  on  a  submarine  and  let  it  perform.  It  is  not  unreasonable 
to  assume  that  new  policies,  whether  enacted  by  Congress  or  the  Navy,  will  force 
logisticians  to  redefine  business  practices  in  the  future.  When  that  time  comes,  any 
decision  to  scrap  and  replace  ANSRS,  improve  it,  or  do  nothing  can  only  be  intelligently 
made  by  researching  a  bank  of  relevant  and  accurate  performance  and  cost  data, 
a.  Develop  performance  indicators. 

The  performance  indicators  provided  in  this  study  should  be  used  as 
preliminary  benchmarks  and  improved  upon.  Shipboard  personnel  should  be  able  to 
download  performance  measures  that  indicate  how  long  a  requisition  has  sat  in  any  or  all 
measurement  segments  including  ordering  time,  technical  screening  time,  awaiting 
approval  time,  awaiting  requisition  number  assignment  time,  awaiting  transmission  time, 
PALT,  shipping  delay,  receipt  processing  time,  etc.  Computer  systems  record  the  date 
and  time  of  every  action;  if  a  key  must  be  stroked  to  accomplish  or  record  any  action,  then 
the  time  interval  between  those  strokes  can  be  measured.  This  will  help  the  users  to 
improve  the  process  by  highlighting  the  bottlenecks.  Similarly,  users  should  be  able  to 
quantify  the  number  and  types  of  nonstandard  procurements  either  submitted  or  awarded, 
error  counts,  transmissions  via  email  versus  SALTS,  etc. 
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b.  Develop  cost  measures. 

Associate  standardized  cost  amounts  to  each  performance  measurement. 
Measurement  of  costs  may  be  useful  to  ships  and  other  end-users  interested  in  determining 
how  much  of  their  operating  budget  is  spent  on  open  procurements.  However,  costs  are 
more  likely  to  be  of  use  at  the  FISC  and  NAVICP  levels,  where  specialization  of  labor  and 
tasking  is  more  prevalent  and  thus  more  susceptible  to  budgetaiy  influences.  One  can 
imagine,  however,  that  if  FISCs  ever  become  Working  Capital  Fund  (previously:  DBOF) 
activities,  their  customers  will  be  very  interested  in  cost  measurements. 

B.  PERIPHERAL  ISSUES 

1.  Credit  Card  Usage 

Research  data  implies  that  credit  cards  are  being  used,  to  an  unknown  extent,  to 
circumvent  supply  system  repair  part  logistical  support  for  equipment  repair.  As  stated 
earlier,  this  could  have  serious  readiness  implications  for  both  short-term  and  long-term 
readiness.  Yet  it  may  also  foretell  how  future  support,  especially  for  CANDI  equipment, 
will  be  conducted.  Since  ANSRS  captures  credit  card  procurement  data,  it  may  play  a 
pivotal  role  in  the  development  and  implementation  of  future  logistics  support  procedures. 
Further  research  may  provide  some  useful  insights  or  conclusions. 

2.  Technical  Libraries 

ANSRS  allows  the  user  to  access  technical  libraries  online.  This,  in  itself,  is  not 
justification  for  reducing  or  eliminating  backup  manual  library  resources.  Ships  sometimes 
lose  all  power  in  emergencies,  and  then  is  not  the  time  to  have  no  means  for  researching 
technical  information.  It  may  be  of  benefit  to  study  if  and  how  the  push  for  “paperless 
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environments”  and  systems  automation  affects  the  Navy’s  ability  to  provide  hard-copy 
backup  resources. 
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APPENDIX  A:  TECHNICAL  SCREENING  EXPERT  SYSTEM  (TSES)  CAPABILITIES 

Source:  Ref.  13 

1 .  Is  Local  Area  Network  (LAN)  compatible,  requires  10  MB  of  hard  disk  space,  approximately  450  KB 
of  free  RAM,  and  DOS  3.3  or  above. 

2.  Is  user-friendly,  has  a  User’s  Manual,  Tutorial,  and  context-sensitive  Help  System  available  with  the 
FI  function  key. 

3 .  Incorporates  a  Training  Manual  utilized  at  on-site  training  sessions  and  provided  to  the  user  facility 
for  additional  training. 

4.  Program  Manager  distributes  newsletter  quarterly  with  information  relevant  to  TSES. 

5 .  Program  Manager  and  support  personnel  update  all  databases  and  reference  information  prior  to  each 
quarterly  distribution.  At  present,  this  is  done  via  discs,  scanning,  etc. 

6.  Transmits  data  via  SALTS,  MODEM,  DISC,  Bulletin  Board,  INTERNET. 

7.  Distinguishes  by  Unit  Identification  Code  (UIC)  designator  (ex.  USS)  or,  if  not  identified,  by  the  first 
letter  of  the  requisition  to  determine  if  the  buy  is  for  ship  or  shore  use  and,  accordingly,  follows  two 
different  logic  paths. 

8 .  Provides  the  user  the  ability  to  automatically  “fill  out”  80-card  column  MILSTRIP  data  in  the  Local 
Database  and  transmit  this  information  electronically  to  NAVICP-M  for  input  into  the  nonstandard 
database  for  inclusion  in  the  next  quarterly  distribution. 

9.  Interfaces  with  eight  other  data  information  modules,  references,  subscriptions  at  the  user’s 
discretion. 

10.  Upon  input  of  a  NSN,  Part  Number  or  Name,  automatically  searches  the  NonStandard  Database,  as 
well  as,  five  (5)  other  resident  and  one  non-resident  database:  Local,  Plastic  Removal  In  Marine 
Environment  (PRIME),  Local  HazMat  Authorized  Use  List  (AUL),  Ships  Hazardous  Material  List 
(SHML),  Authorized  Medical/Dental  Allowance  List  (AMAL/ADAL),  and  a  non-resident  database, 
the  Hazardous  Inventory  Control  System  (HICS)  (if  installed  as  activity  LAN  or  PC  application). 
Search  provides  information,  such  as:  the  item  is  hazardous,  non-hazardous;  authorized,  prohibited; 
replacement  NSN  available;  ODS;  plastic  with  a  non-plastic  alternative;  medical/dental;  available  in 
HAZMIN  Center;  requires  a  Material  Safety  Data  Sheet  (MSDS),  SHML  Feedback  Report  (SFR), 
NAVSUP  Form  87,  etc. 

1 1 .  Provides  reference  material  via  Function  Keys,  View  Data  Menu,  Database  Tools,  some  of  which  are: 
FED-STD-313C,  Tables  I  and  II  (Appendix  A),  Material  Safety  Data,  Transportation  Data  and 
Disposal  Data  for  Hazardous  Materials  Furnished  to  Government  Activities;  Federal  Supply 
Classification  (FSC)  Catalog,  H2-1,  Part  1,  Groups  and  Classes;  NAVSUPINST  4200.85C,  Enclosure 
3,  Shore  and  Fleet  small  Purchase  and  Other  Simplified  Purchase  Procedures;  Dual  Cognizance 
(COG)  Codes;  Special  Material  Identification  Codes  (SMIC);  Type  of  Storage  Codes  (TOS);  Special 
Material  Content  Codes  (SMCC);  Shelf/Life  (S/L)  Codes;  Shelf  Life  Action  Codes  (SLAC);  Unit  of 
Issue  (UI)  Codes;  Hazardous  Characteristics  Codes  (HCC);  Hazardous  Material  Identification  Codes 
(HMIC);  Unit  Identification  Codes  (UIC);  Acquisition  Advice  Codes  (AAC);  Ozone  Depleting 
Substance  (ODS)  Chemical  Names;  NAVSUP/NA VSE A/NAV AIR/MILITARY  SEALIFT 
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COMMAND/MARINE  CORPS  Authorized  User  List  of  the  ODS  Reserve;  ODS  Procurement 
Approvals,  etc. 

12.  Automatically  produces  correspondence  and  forms,  capturing  input  information,  providing  the  ability 
for  the  customer  to  personalize  such  correspondence/forms  (if  standardization  is  not  essential),  direct 
to  a  file  and/or  transmit  via  SALTS,  MODEM,  DISC,  INTERNET. 

13.  Allows  the  user  to  Batch  Process  (input  a  disc  in  ASCII  text  file)  and  automatically  screen  NSN 
requisitions,  divide  them  into  those  authorized  and  not  authorized,  create  a  historical  summary  of 
those  not  authorized. 

14.  Provides  a  Batch  modify  module  to  enable  the  user  to  change  all  entries  in  one  specific  field  in  either 
the  Local  or  Local  HazMat  AUL  Databases. 

15.  Provides  a  Suspense  Tickler  File  on-line  which  dates  those  items  that  require  an  SFR  or  NAVSUP 
Form  87  due-back  within  a  specified  time. 

16.  Provides  a  summary  of  all  action  either  input  or  captured  from  the  databases  and  system  queries  in  a 
format  which  can  be  electronically  transmitted  or  saved  to  a  file. 

17.  Creates  a  historical  summary  which  is  accessed  via  a  Function  key  and  is  saved  for  a  period  of  six 
months. 

18.  Enables  user,  via  Report  Generator,  to  design  and  personalize  reports,  capturing  specific  database 
fields,  tailored  by  activity  to  print  required  reporting  information.  These  forms  are  saved  in  the  report 
generator,  making  it  easy  to  print  the  same  information  weekly,  monthly,  quarterly. 

19.  Provides  letter  built  into  system  for  electronic  transmission,  indicating  any  problems  or  enhancements 
to  system.  Personal  contact  via  phone,  and  customer  visits  by  Programmer,  Program  Manager  at 
NAVSUP  and  NAVICP-M  and  other  support  personnel  has  provided  and  continues  to  provide 
expeditious  programming  updates.  At  present,  includes  desk  top  manager  amenities,  such  as, 
calculator,  appointment  calendar,  etc. 
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APPENDIX  B:  STANDARD  PROCESSING  ENVIRONMENT  FOR  ELECTRONIC 
DOCUMENTS  (SPEED) 

Source:  Ref.  13 

1.  APPLICATION  A  runs  Customer  Workstation  via  Emulator  Control  Screen  and  Workstation  System 
Screen. 

a.  Allows  user  to  show,  edit  and  browse  requisitions,  utilizing  data  validation  codes,  expedite  codes 
and  release  authorization  codes. 

b.  Sends  requisition  to  Customer-Host  via  SALTS  subsequent  to  an  error  validation  check. 

2.  APPLICATION  B  runs  Customer-Host  via  Emulator  Control  Screen  and  Customer-Host  System 
Screen. 

a.  Allows  user  to  get  requisitions  via  filename,  select  report  options  and  view  screen  display. 

b.  Permits  user  to  approve,  edit  and  browse  documents. 

c.  Transmits,  subsequent  to  validation,  approved  requisitions  to  SALTS. 

d.  Provides  a  system  action  summary  page  prior  to  exit  to  processing  screen. 

3 .  APPLICATION  C  runs  FISC-HOST  via  Emulator  Control  Screen  and  FISC-Host  System  Screen. 

a.  Host  receives  requisitions,  downloads  requisitions  from  SALTS,  processes  receipts  and  posts 
actions  to  LAN. 

4 .  APPLICATION  D  runs  FISC-TECH  via  Emulator  Screen  and  FISC-TECH  System  Screen. 

a.  Allows  user  to  get  incoming  requisitions,  download  summary  screen,  review  requisitions,  select 
single  requisition  to  approve  via  browse,  and  edit  requisition. 

b.  Displays  MCRL-data,  tech  advisories,  opens  pipeline  and  status  input  window. 

c.  Displays  status  and  tech  certification. 

d.  Releases  documents  for  final  processing. 

e.  Transmits  all  completed  work  to  APADE/UADPS/SALTS. 
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APPENDIX  C:  ANSRS  OBJECTIVES 


Source:  Ref.  13 


SYSTEM 

The  system  objectives  are  analogous  to  all  aspects  of  the  ANSRS  program  and  identify  what  the  whole 

system  will  do  subsequent  to  meeting  all  the  objectives  listed. 

1.  To  provide  a  single  automated  requisition  processing/technical  screening  system  that  will 
accommodate  all  new  technologies  and  utilize  the  best  of  the  existing  systems  in  order  to  facilitate 
centralization  and  optimization  of  the  technical  screening  function  for  nonstandard  material 
requisitions. 

2.  To  perform  a  basic-level  technical  review  (customer  level)  of  each  requirement,  generate  an  electronic 
requisition,  download  requisition  via  SALTS  and  forward  to  the  CTA/F1SC. 

3.  To  automatically  screen  incoming  electronic  requisitions  through  the  CTA  and  generate  status  in  the 
NAVICP  Document  Status  File  (DSF). 

4.  To  build  validations  and  edits  into  the  system  to  enable  communication/interface  between  all 
participants  via  SALTS/Electronic  Data  Interchange  (EDI),  and  the  Military  Standard  Transaction 
Requisitioning  and  Issue  Procedures  (MILSTRIP)  via  Uniform  Inventory  Control  Program 
(mCP)/Uniform  Automated  Data  Processing  (UADPS)/Shipboard  Uniform  Automated  Data 
Processing  System  (SUADPS)  transmissions,  so  as  to  maintain  status  and  demand  criteria. 

5.  To  screen  out  exceptions  and  queue  those  items  with  inadequate  data  for  manual  review. 

6.  To  produce  a  database  of  all  nonstandard  requisitions  resident,  maintained,  updated  at  the  CTA  and 
distributed  via  CD-ROM  as  part  of  the  Customer  and  Procurement  Activity  Modules. 

7.  To  assure  optimum  visibility  of  all  nonstandard  material  buys. 

8.  To  design  a  user-friendly,  flexible  system  that  will  minimize  hardware  requirements  and  will  meet 
the  needs  of  a  broad  range  of  customers,  from  afloat  to  ashore. 

9.  To  develop  on-line  help,  data  field  validation  tests  and  error  correction  to  assist  in  document 
preparation. 

10.  To  develop  customer  specific  guidelines  and  detailed  standardized  instructions  as  to  how  to  use  the 
system,  how  to  technical  screen  items  and  a  decision  matrix  as  to  which  items  will  need  “deep” 
technical  screening,  at  the  customer  level  and  the  central  site. 

1 1 .  To  provide  on-line  technical,  relevant  Department  of  Defense  information  in  the  form  of  a  quarterly 
newsletter.  This  will  include  new  instructions,  executive  orders,  etc. 

12.  To  develop  a  methodology  to  systematically  update  all  databases,  reference  information,  etc.  that 
reside  in  the  Customer,  Procurement  Activity  and  Host  modules. 

13.  To  develop  system  implementation  plans. 

14.  To  develop  contingency  plans. 
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CUSTOMER  SUPPORT  MODULE 


The  Customer  Support  Module  resides  at  the  user  activity  and  is  the  first  step  in  the  technical  screening 

process.  The  objectives  inherent  in  the  design  of  this  module  are  as  follows: 

1 .  To  design  and  develop  a  customer  support  module,  utilizing  the  electronic  nonstandard  requisitioning 
document  for  client-server  and  stand-alone  systems. 

2.  To  provide  in  this  customer  module  a  nonstandard  database  that  is  updated  from  the  CTA  via  CD- 
ROM. 

3.  To  allow  the  customer  to  automatically  “fill  out”  a  requisition  (DD  Form  1348-6,  NAVSUP  Form 
1250-2,  DD  Form  1 149  or  80-card  column  MILSTRIP  information),  assign  a  requisition  number  via 
SUADPS/UADPS  and  transmit  electronically  to  CTA  or  Procurement  Activity  Modules  via  EDI, 
SALTS,  MODEM. 

4.  To  enable  the  customer  to  initially  tech  screen  buys  to  identify  need,  gather  data  via  CD-ROM 
nonstandard  database,  Federal  Logistics  Information  System  (FLIS),  HAYSTACK,  PARTSMASTER, 
etc.,  identify  interchangeable  or  substitute  items  and  eliminate  those  non-exigent  items  which  do  not 
need  to  process  through  central  database  technical  screening  (ex:  is  there  a  NSN,  does  it  fit  the 
purchase  card  requirements,  etc.).  These  requisitions  will  bypass  the  Central  Database;  however,  they 
will  be  captured  in  the  Demand  Recording  Document  (BHJ)  tracking  system  via  Automated 
Procurement  and  Accounting  Data  Entry  (APADE)  suspense  files. 

5.  To  provide  as  much  reference  material/instructions  (edits)  on-line  as  is  feasible  to  save  additional 
hours  of  searching  hardcopy  manuals,  etc. 

6.  To  develop  on-line  help,  built-in  users’  manual  and  print  down  capability. 

7.  To  develop  data  field  validation  tests  and  error  correction  to  assist  in  document  preparation  (for  ex. 
Fund  code,  project  code,  accounting  line  data). 

8.  To  provide  a  method  to  configure  system  to  execute  (interface/”hotkey”)  other  data  information 
modules,  references,  subscriptions. 

9.  To  give  the  customer  the  option  to  batch  process  requisitions,  using  ASCII  text  files,  and/or  batch 
modify  databases,  selecting  a  field  and  replacing  the  values  with  new  data,  if  this  method  is  feasible. 

10.  To  establish  both  automated  and  manual  parameters  and  procedures  for  database  file  maintenance; 
automatically  track  items  in  the  nonstandard  database  which  were  assigned  a  NSN  or  a  NSN  was 
found  in  the  screening  process,  and  remove  them  from  the  nonstandard  database. 

1 1.  To  electronically  produce  correspondence/forms  which  relate  to  the  system  processes,  capture  input 
data  on  these  letters/forms,  provide  the  ability  for  the  customer  to  personalize  such  correspondence 
and  forms  (if  standardization  is  not  essential),  direct  to  a  file  and/or  transmit  via  EDI,  SALTS, 
MODEM. 

12.  To  provide  the  capability  to  create  a  system  summary  of  all  actions  taken  during  customer  screening 
to  remain  in  a  history  file  for  a  predetermined  time. 

13.  To  build  summary  transmission  of  all  data  input  into  system  and  extracted  from  cognizant  databases. 

14.  To  create  a  report  generator  capable  of  designing  customer  specific  reports  for  administrative  tracking 
and  reporting  purposes. 
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15.  To  empower  the  customer  with  the  ability  to  suggest  other  enhancements,  problems  with  the  system, 
via  dedicated  phone  line,  which  will  improve  customer  support  modules  and  create  an  efficient,  time¬ 
saving  desk  top  manager,  reducing  administrative  workload.  To  continue  program  development  as 
the  system  develops  and  subsequent  to  implementation. 

16.  To  enable  ANSRS  participants  to  input,  edit  and  receive  requisitions  in  MILS-standard  format. 

17.  To  enable  download  of  data  files  or  requisitioning  transactions  to  floppy  discs  for  transfer  to  PCs  not 
linked  to  local  area  network  (LAN). 

18.  To  screen  incoming  requisitions  for  items  containing  hazardous  materials,  establishing  correct  data 
requirements  for  ordering;  determined  whether  requisitioned  item  is  approved  for  user  activity; 
determine  whether  requisitioned  item  is  coded  for  environmental  or  other  special  recovery  program 
such  as  the  Ozone  Depleting  Substance  (ODS)  program;  and  determine  if  there  are  environmentally 
friendly  substitutes. 

19.  To  provide  frequent  automatic  backup  capability  to  prevent  loss  of  data  and/or  transactions  during 
program  use. 

20.  To  provide  immediate  suggestion  to  originator  on  where  to  send  requisition  for  screening  and 
procurement,  i.e.  FISC  or  CTA. 

21.  To  develop  approval  protocols  and  security  checks  for  appropriate  ordering  authorizations  to  be  input 
to  database. 

22.  To  track  transactions,  performance  of  cognizant  personnel  and  pertinent  Automated  Data  Processing 
(ADP)  systems  through  key  events  in  screening  and  procurement  processes. 

23.  To  provide  retech  capability  for  actions  entered  erroneously. 

24.  To  develop  inquiry  only  option,  creating  ability  to  browse  database  without  actually  processing  a 
requisition. 

25.  To  provide  capability  to  archive  prior  procurement  data  and  build  a  historical  file. 

26.  To  provide  capability  to  input  nonstandard  data  or  other  information  which  may  enhance  tech 
screening  capability;  this  includes  identification  of  weapon  system  application  the  specific 
procurement  is  meant  to  support. 


PROCUREMENT  ACTIVITY  MODULE 

The  Procurement  Activity  Module  will  include  all  the  objectives  identified  in  the  Customer  Module 
(except  where  they  are  identified  as  customer  specific  objectives)  with  the  addition  of  the  following: 

1 .  To  provide  a  system  to  the  FISC  which  receives  SALTS/EDI  transmissions,  provides  technical 
screening  capability  at  the  FISC,  provides  interface  with  APADE,  and  forward  transmissions  to  the 
CTA  for  cases  requiring  “deep”  technical  review. 

2.  To  enable  LAN  capability,  providing  personnel  the  ability  to  share  and  forward  case-specific 
information. 
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3.  To  receive  and  transmit  requisitions  and  related  data  via  land-based  computer  networks  such  as  the 
Internet  and  SLICENET. 

4.  To  enable  development  of  comprehensive  demand  database,  capturing  demand  on  items  bought 
locally  by  FISCs. 

5.  To  permit  speed  routing  of  requisitions  to  cognizant  material  management  activity  (such  as  “MD” 
source-coded  items  which  will  be  made  or  assembled  instead  of  purchased). 

6.  To  create  FISC-generated  BD  status  in  UADPS-SP  Requisition  Status  File  (RSF)  and  provide  status 
to  customer  via  AUTODIN. 

7.  To  provide  technical  screening  status  information  to  customer/CTA. 

8.  To  feed  FISC  developed  screening  data,  procurement  information  and  technical  screening  actions  to 
the  CTA  for  central  storage  and  dissemination  to  other  FISCs  to  preclude  duplication  of  effort,  this 
includes  periodic  reconciliation  of  FISC  and  CTA  databases. 

9.  To  forward  technical  screening  data  and  procurement  orders  to  AP ADE  programs. 

10.  To  provide  capability  to  receive  input  transactions  in  military  standard  format. 

11.  To  enable  screening  personnel  to  input  data  into  the  database. 


HOST  MODULE 

The  Host/Central  Tech  Activity  Module  will  include  all  the  objectives  identified  in  the  Customer  and 

Procurement  Activity  Modules  (except  where  they  are  identified  as  customer  or  FISC  specific  objectives) 

with  the  addition  of  the  following: 

1.  To  design  and  develop  a  Central  Database  or  Host  Module  capable  of  accepting  EDI,  SALTS, 
MODEM  transmissions  of  nonstandard  requisitions.  This  will  ensure  that  all  “deep”  technical 
screening  of  nonstandard  buys  occurs  at  the  central  site  and  is  accomplished  in  a  standardized  format, 
enabling  the  central  site  to  maintain  an  up-to-date  technical  library,  easily  accessible  to  screening 
personnel. 

2.  To  generate  BD  status  in  DSF  upon  receipt  (B01  input  to  UICP),  creates  requisition  status 
information  and  provides  status  to  customer  via  AUTODIN. 

3.  To  generate  BM  status  in  DSF  upon  referral  to  APADE  (input  to  UICP),  reflects  referral  of 
procurement  package  to  FISC  after  tech  screening,  provides  status  to  customer  via  AUTODIN. 

4.  To  generate  BV  status  in  DSF  upon  referral  to  Integrated  Technical  Item  Management  and 
Procurement  (IT3MP)  (input  into  UICP),  informs  customer  via  AUTODIN  that  item  is  being  procured 
by  NAVICP  and  will  be  delivered  directly. 

5.  To  electronically  capture  APADE  data  into  the  BHJ  application,  matching  Allowance  Parts  List 
(APL)  and  technical  data  from  ANSRS  nonstandard  database  base  on  document  ID.  To  assign  a 
unique  Local  Stock  Number  (LSN).  To  report  the  purchase  of  nonstandard  material  to 
NAVICP/Integrated  Material  Manager  (EMM)  databases,  BHJ  input  to  UICP. 
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6.  To  maintain  status  of  buys  screened  and  procured  by  NAV1CP-P.  To  interface  with  NAVICP-P  in  the 
distribution  of  aviation  items,  status  (number  of  items  transmitted  to  NAVICP-P,  data  sent,  and  action 
taken),  and  update  of  the  nonstandard  database. 

7.  To  accept  technical  screening  and  procurement  referrals  from  the  FISCs. 

8.  To  correctly  prioritize  each  buy  and  determine  the  criticality  of  timely  processing.  A  matrix  will  be 
loaded  into  the  system  to  automatically  determine  priority  and  mission  critical  elements  and  a  turn 
around  time  (TAT)  will  be  established  based  on  these  elements. 

9.  To  define  Central  Technical  Database  fields  and  FLIS  information  necessary  for  “deep”  tech 
screening. 

10.  To  perform  “deep”  technical  screening  on  those  items  which  were  not  system  compatible  subsequent 
to  Customer  Module,  Central  Technical  Database  screening  (ex.  Items  that  do  not  cross  to  a  NSN, 
Hazardous  Material  items,  etc.) 

11.  To  perform  “deep”  technical  screening  using  all  available  references,  technical  libraiy  material, 
including,  but  not  limited  to:  Master  Item  File  (MIF),  Master  Cross  Reference  List  (MCRL), 
historical  data,  procurement  information.  Navy  Publications,  drawings  (EDMICS),  MIL-SPECS, 

FLIS,  FEDLOG,  PartsMaster,  SNAPSHOT,  Inventory  Locator  Service  (ILS),  etc.  To  provide  as 
much  reference  material/instructions  on-line  as  is  feasible  to  save  additional  hours  of  searching 
hardcopy  manuals,  etc.,  and  to  provide  a  method  configurable  to  execute  (“hotkey55)  other  data 
information  modules/references/subscriptions. 

12.  To  update  nonstandard  database  in  ANSRS  with  predetermined  types  of  items  for  resubmission  to 
Customer/Procurement  Activity  Support  Modules  via  CD-ROM  on  a  predetermined  basis. 

13.  To  electronically  provide  supply  options,  action  posted  on  requisition,  date  of  action,  etc.  to  all  parties 
involved. 

14.  To  electronically  submit  to  correct  procurement  activity  and  record  all  actions  taken. 
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APPENDIX  D:  LIST  OF  SITES  IMPLEMENTED 


FISC  Jacksonville 

♦  USS  GETTYSBURG  (CG  64) 

♦  USS  PHILIPPINE  SEA  (CG  58) 

FISC  Norfolk 

♦  Pierside  CEP  170/Q71 

♦  USS  EMORY  S  LAND  (AS  39) 

♦  USS  SAIPAN  (LHA  2) 

♦  NAS  Norfolk 

♦  NAS  Willow  Grove 

FISC  Pearl  Harbor 

♦  FISC  Pearl  Harbor-Barber’s  Point 

♦  USS  CUSHING  (DD  985) 

♦  USS  LAKE  CHAMPLAIN  (CG  57) 

♦  USS  PAUL  HAMILTON  (DDG  60) 

♦  NAS  Barber’s  Point 

FISC  Puget  Sound 

♦  USS  ABRAHAM  LINCOLN  (CVN  72) 

♦  USS  CARL  VINSON  (CVN  70) 

FISC  San  Diego 

♦  FISC  San  Diego-Broadway 

♦  FISC  San  Diego-Point  Loma 

♦  USS  MCKEE  (AS  41) 

♦  USS  SHILOH  (CG  67) 

♦  USS  TARAWA  (AS  41) 

FISC  Yokosuka 

♦  FISC  Yokosuka-Sasebo 

♦  USS  BELLEAU  WOOD  (LHA  2) 

♦  USS  RODNEY  M  DAVIS  (FFG  60) 

♦  SRF  Yokosuka 

♦  SRF  Yokosuka-Sasebo 

♦  COMFELACT  Yokosuka 

♦  COMFLEACT  Sasebo 
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APPENDIX  E:  QUESTIONNAIRE 


ANSRS  QUESTIONNAIRE 

Note:  Some  questions  may  not  be  pertinent,  in  entirety  or  in  part,  to  your  job.  Please  answer  as  much  of 
any  question  as  you  can,  to  the  best  of  your  knowledge.  If  you  don’t  know  part  or  all  of  any  question,  or  if 
the  question  is  N/A,  say  so. 

1.  Manual  Open  Purchase  Process  (Pre-ANSRS,  Pre-Credit  Card) 

a.  Briefly  describe  the  process  flow  (from  end-user  to  the  contracting  activity’s  customer  service 
desk),  approximate  time  involved  in  each  step,  the  personnel  involved  in  each  step,  and  any 
paperwork  or  document  requirements. 

b.  What  problems  did  (do)  you  encounter  with  the  manual  open  purchase  process?  What  and 
where  in  the  process  were  (are)  the  bottlenecks? 

c.  Approximately  how  long  did  (does)  it  take  to  receive  your  material  this  way? 

2.  IMPAC  Credit  Card 

a.  Do  you  currently  use  the  IMPAC  credit  card?  Y  N 

b.  If  so,  since  when? 

c.  Describe  the  workload  that  was  reduced  or  eliminated.  By  what  percentage? 

d.  Describe  the  workload  that  was  increased  or  created.  By  what  percentage? 

e.  Do  you  feel  that  the  credit  card  makes  your  job  easier?  Harder?  Why? 


3.  ANSRS  Training 

a .  When  did  you  first  hear  about  ANSRS? 

b.  What  type(s)  of  training  did  you  receive?  Duration? 

■  None 

■  Self-training 

■  1  on  1 

■  Group 

■  Lecture 

■  Hands-on 

■  Other  (describe) 

c.  Would  you  describe  the  training  as  good,  thorough,  and  worthwhile?  If  not,  what  would 
have  helped? 

d.  At  what  point  did  you  understand  what  ANSRS  was  intended  to  do? 

■  Pre-training 

■  During  training 
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■  After  working  with  it 

■  Still  somewhat  unclear 

e.  At  what  point  did  you  understand  how  to  use  ANSRS? 

■  During  training 

■  After  working  with  it 

■  Still  somewhat  unclear 

f.  How  difficult  is  it  for  you  to  adequately  train  someone  within  your  organization  on  ANSRS? 

■  Haven’t  had  to  yet 

■  Not  difficult/easy 

■  Moderately  difficult 

■  Very  difficult/hard 

■  Impossible 

g.  How  would  you  improve  ANSRS  training  within  your  organization? 

h.  Do  you  know  where  to  get  assistance  within  your  organization  if  needed?  Y  N 

i.  Do  you  know  where  to  get  assistance  outside  your  organization  if  needed?  Y  N 

j .  Do  you  know  how  and  where  to  send  feedback  or  suggestions?  Y  N 


4.  ANSRS  Usage 

a .  How  often  do  you  use  ANSRS? 

■  Daily 

■  Weekly 

■  A  few  times  per  month 

■  Rarely 

■  Never 

b.  What  do  you  use  ANSRS  for? 

■  NSN  screening 

■  HAZMAT  screening 

■  Mandatory  source  (NIB/NISH/UNICOR)  screening 

■  Credit  card  procurements 

■  Other  small  purchase  procurements 

■  Large  procurements 

■  Other  (describe) 

c.  Who  uses  ANSRS  in  your  organization? 

■  Commanding  Officer 

■  Executive  Officer 

■  Supply  Officer 

■  HAZMAT  Officer 

■  Storekeepers  (how  many?) 

■  RPPOs  (how  many?) 

■  Others  (describe) 
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d.  Briefly  describe  the  process  flow  (from  end-user  to  the  contracting  activity’s  customer  service 
desk),  approximate  time  involved  in  each  step,  the  personnel  involved  in  each  step,  and  any 
paperwork  or  document  requirements. 

e.  What  and  where  in  the  process  are  the  bottlenecks? 

f.  Approximately  how  long  does  it  take  to  receive  your  material  this  way? 

g.  Does  ANSRS  decrease  your  workload  (e.g.  saves  time,  saves  paperwork)?  Y  N 

h.  If  yes,  describe  how  and  rank  in  order  of  importance  to  you. 

i.  Does  ANSRS  increase  your  workload  in  any  area?  Y  N 

j .  If  yes,  describe  how. 

k.  What  should  ANSRS  do  for  you  that  it  cannot  now  do? 

l.  Does  your  command  receive  a  Non-Standard  Data  Base  (NSDB)  update  on  a  regular  basis? 

Y  N 

m.  If  yes,  how  often? 

n.  Does  ANSRS  interface  with  FEDLOG?  Y  N 

o.  Is  ANSRS  installed  on  a  LAN  within  your  organization?  Y  N 

p.  Do  you  like  ANSRS?  Y  N 


5.  Miscellaneous 


a.  On  average,  how  many  open  purchase  requisitions  do  you  submit  per  month  for  credit  card 
purchases? 

■  Less  than  6 

■  6-10 

■  11-15 

■  16-20 

■  21-25 

■  More  than  25  (how  many?) 

b .  Non-credit  card  small  purchases? 

■  Less  than  3 

■  3-5 

■  6-10 

■  11-15 

■  16-20 

■  More  than  20  (how  many?) 

c.  Large  purchases? 

■  1 
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■  2 

■  3 

■  4 

■  More  than  4  (how  many?) 

d.  Approximately  what  percentage  of  _ _ open  purchases  are  for  repair  parts  (vice 

consumables,  equipage,  services,  etc.)? 

■  Credit  card 

■  Non-credit  card  small 

■  Large 

e.  Approximately  what  percentage  of _ open  purchases  are  procured  using  ANSRS? 

■  Credit  card 

■  Non-credit  card  small 

■  Large 

f.  What  kinds  and  how  much  extra  equipage  (e.g.  terminals)  was  needed  to  implement  ANSRS 
within  your  organization? 


5.  Additional  Comments 


Date  ANSRS  installed: 

Date  ANSRS  usage  began: 

Rate/rank: 

Position  (SUPPO,  Leading  SK,  RPPO,  etc.): 

Name/phone  number/e-mail/address  (optional): 

May  I  contact  you  if  I  have  any  follow-up  questions?  Y  N 
Would  you  like  a  summary  copy  of  the  results?  Y  N 
THANK  YOU!! 
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APPENDIX  F:  TOP  REASONS  WHY  PROCUREMENT  DOCUMENTS  GET  SENT  BACK  TO 
SHIPS  FROM  FISC 

1 .  Insufficient  description  on  forms/poor  description  of  competitive  items  -  could  be  two  manufacturers 
with  similar  items  -  include  size,  dimensions,  type,  etc.  for  a  better  description 

2.  Missing  waivers  for  using  mandatoiy  sources 

3 .  Missing  justification  for  sole  source  requests 

4.  Incomplete  accounting  information  -  accounting  spread,  TAC 

5.  Missing  justification  for  ADP/IT  requests 

6.  Missing  requisition/document  numbers  -  each  line  item  needs  a  requisition  number.  APADE  specific 
-  cannot  have  one  requisition  number  for  15  line  items 

7.  Missing  approval  signatures 

8.  Missing  HAZMAT-related  attachments  -  SHML  and  MSDS 

9.  Missing  GSA  contract  numbers 

10.  Missing  1DTC  contract  numbers 

1 1 .  Original  equipment  manufacturer  (OEM)  not  identified 
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